Blu Homes, America’s leading provider of premium prefab homes, launched its newly redesigned website. Created by Nurun’s office in San Francisco, the elegant, responsively designed website reflects Blu Homes’ smart and innovative approach to creating beautiful, high-performance homes for discerning homebuyers who care about design, quality and sustainability.
Nurun was responsible for in-depth consumer research, branding, visual look and feel, site architecture, and interactive content development for the new BluHomes.com. The result is a web experience that features a simplified, entirely new site organization that provides a clear, narrative journey that builds as site visitors explore the site.
Blu’s proprietary information technology enables homebuyers to create their unique home design online in 3-D, and receive a clear, fixed price. Blu Homes are built in the factory, shipped across North America, and unfolded on-site to reveal soaring ceilings and walls of glass that let the outdoors in. Blu Homes start at $210,000 for a 2-bedroom home and go up towards $495,000+ for a 5-bedroom home.
If your only tool is a hammer, every problem will look like a nail.
If your only tool is e-mail, every minute will be spent checking your inbox.
Unicorns are highly sought-after individuals in the creative world. They are considered to be great visual designers who also understand user experience and interaction design, know how to write code, and are generally one-person Swiss Army knives that can fill in any missing roles on a project.
Most teams don’t have unicorns, but fortunately they don’t need them either. Plenty of tools have popped up that allow teams to collaborate and communicate better, and to produce cleaner, faster, and better work:
Tools for Collaboration
Collaboration and communication form the basis of any functional project team. If a team can’t communicate ideas, designs, and deadlines effectively, then any products or outputs will suffer as a consequence.
The following tools provide alternate ways to communicate project details outside of email.
Trello is a product that lets users easily create and collaborate on anything from Kanban boards to shopping lists.
Prototype Pipeline Tools
Depending on a project’s needs, a project might only need to be presented in a PhotoShop. But often the PhotoShop files are just an approximation of what a design might look like in a browser. Sometimes the designs have to be prototyped, tested, and iterated upon.
For larger teams and long-term projects, setting up prototypes in a more production-type environment is most effective. Using the previously mentioned tools to create an internal website to keep track of documentation, requirements, style guides, and etc., allow different teams to start curating information and store it in a central place.
There are many options for designing, prototyping, and collaborating. With the advent of many tools available for both production and prototyping, designers with even a limited knowledge of code can produce work that is faster, richer, and more interactive.
Nature of the Beast
Producing great work can be a turbulent process. Consider yourself lucky if you’ve never run into any schedule, budget or client problems. But if you’re like the rest of us, you can always count on people to change their minds, make last-minute changes, and miscommunicate, leading to stretched budgets, broken project schedules, and frustrated teams. That’s just the nature of the beast.
Searching for Unicorns
With the constant flux of requirements, some companies increasingly turn to “unicorns,” individuals who are equally talented in both visual and user experience design, as well as front-end and perhaps even back-end development.
These companies realize the power of an all-in-one individual. They want people who can first design complex solutions, then elegantly realize them. They need people who can save them from countless hours on meetings and presentations spent negotiating between designers and developers; they want someone who can do it all, front to back. They want a jack, queen, and king of all trades.
Almost as mythical and as rare as the unicorns found in legend, these workplace unicorns ephemerally graze on the plains of the Internet. In the rare likelihood that you might encounter one, chances are good that they’ve already been picked up by the likes of either Google or Facebook. And if you were lucky enough to catch one, you probably couldn’t afford to keep it.
Could a single unicorn produce better and faster work than a small, well-rounded group of designers and developers working together? The Internet wonders: what if designers could simply learn how to write some code? For some, the answer is a resounding “yes,” but for others it’s not so simple.
Focus on Shipping
The ultimate responsibility of the designer and the developer is to ship a great product. Instead of asking ourselves if our designers should learn to code, we should be asking if learning to code can help designers ship better products.
The designer’s job is to create the best possible user experience. If knowing how to code helps designers design a better experience, then they should probably learn to code. There are many benefits to learning code: it may help designers better communicate ideas and better command respect with developers. It may also help them explore technical possibilities and constraints, as well as maintain their original design vision throughout the process.
Unicorns are popular because they can design and implement their own visions. They are multidisciplinary chameleons that shift from one role to another, filling in knowledge gaps that might otherwise require an entire team. Unicorns can adapt and iterate, and save time otherwise lost through meetings and miscommunication. They are valuable because they have potential to iterate faster through requirements, ideas, and implementation cycles than project teams.
But relying on one unicorn is to put all the eggs in one basket. They’re not cheap, and they can’t do everyone’s work at once.
A team of designers and developers with the right knowledge and tools can work just as well as unicorns. Each member doesn’t need to know how to design and build everything, but just enough to strengthen the team. A designer might save time by directly editing the style sheet of a prototype instead of updating dozens of comps and passing them on to a developer. Similarly, developers might fix design elements on their own, without any designer feedback, if they knew how to improve on the product. Designers and developers often hold each other accountable to look for—and to fix—the small details, many of which tend to slip through the cracks of the initial design.
Getting the small details right is what takes a product from “okay” to “perfect.” But getting to that point requires the full participation of each team member. Projects are living and flexible, and the teams behind them must adapt to their constantly changing needs. The team must communicate frequently and help each other as requirements and demands evolve. However, with the right tools and the right combination of knowledge, they would have no problems catching up with the nimble unicorn.
To Code or Not to Code
If you’re a designer, and you came in wondering whether you should learn code, where does all of this leave you? I think yes, you should experience learning code. You need to become familiar with the arduous process of implementing, testing, and rewriting code. You don’t need to produce the most beautiful and functional code, but you should understand that code isn’t magic; that developers need to solve for certain challenges when implementing novel or difficult designs. You will also know how to better convince developers to take the more difficult but more-user-friendly route, if you understood their challenges and could speak their language. Finally, learning code will also improve your own marketability; having a thorough understanding of code will give you an edge over the competition.
After all, a little more knowledge never hurt anyone.
The International Conference on Functional Programming (ICFP) hosts an annual three-day contest to determine “the programming tool of choice for discriminating hackers.” Four members from Nurun participated in this year’s contest.
The essence of the task was to implement AI for a Pac-Man clone called Lambda-Man. The (hypothetical) hardware that the AI was to run on had two computational subsystems: a register based processor that ran the AI for the ghosts, and a stack-based processor that runs the Lambda-Man AI. The lightning round task (deadline: 24 hours) was to create AI for Lambda-Man in the machine code assembly language. The full round task (72 hours) added a requirement to also provide up to four ghost AI programs in the corresponding assembly language, and gave the Lambda-Man AI program access to read the ghost AI code.
Let’s review stack and register-based processors so we know what we’re talking about. Our code is simply a bunch of instructions; processors basically execute these instructions in a systematic manner. A typical instruction takes operands, which is the data required in order to execute the instruction. For example an instruction “Add A and B” has two operands ‘A’ and ‘B’. Then once the instruction is executed, it will produce a result. Stack-based processors and register-based processors differ in the mechanism used for storing and retrieving operands and their results.
Stack-based processors can be thought of as a stack of plates. In order to insert a new plate, we place it on top of the stack. In order to take a plate, we must take it from the top of the pile. This is called Last In First Out. In a stack-based processor, we’re given two functions: push and pop. “Push” will push the data onto the stack and “pop” will simply remove the topmost data from the stack. In order to access the data, we simply pop from the stack, and push the result back into the stack. In this way we always know that needed data is at the top of stack.
Sample instructions for a Stack-Based Processor for adding ‘a’ and ‘b’ (assume stack has a and b pushed accordingly):
Register is a memory storage embedded in the CPU. In the register-based model, code will explicitly mention the register address of the operands. Sample instructions for a Register-Based Processor for adding a and b (Given R1, R2 and R3 as a addresses for the registers)
Solving the Problem
The Lambda-Man AI ran in the processor that executed the instruction in a stack-based manner, where as the Ghost AI ran in the register-based processor. You can see from the above examples that we’re dealing with very low-level languages that are close to machine language. We decided that writing AI in machine code was very unappealing; in order to do something as simple as add two numbers in the stack language we had to write five lines of code. So we decided that instead of writing in assembly we’d instead write a compiler for a higher-level language. We choose Scheme as our source language because it was relatively easy to parse and compile, and we could run our AI on a “real” interpreter or compiler to verify the correctness of our AI independently of the correctness of our compiler.
How do we compile higher-level expressions into low-level assembly language? Let’s walk through the higher-level overview of the process with a simple example:
Given the following ‘if’ control flow written in Scheme:
(if (> 1 2) 42 0)
The first step is to organize the above code into different tokens. For instance, we will recognize ‘(‘ and ‘)’ as delimiter character. In this step, we essentially want to organize the input in the exact way it was given as a input, minus unnecessary space characters.
Now, the next step is to convert the organized tokens into an intermediate representation that can be analyzed.
Given the following hierarchy of objects:
sealed trait Exprcase
class Constant(c: Int) extends Expr
case class Literal(v: String) extends Expr
case class If(test: Expr, thn: Expr, els: Expr) extends Expr
Should yield the following:
If(App(Literal(“>”), Seq(Constant(1), Constant(2))), Constant(42), Constant(0))
Now the final step is the semantic analysis. We will recursively follow the above intermediate representation into the machine code into the final representation below.
The above code will use a stack as persistence storage and evaluates whether the first operand is greater than the second operand. If this is evaluated to true it returns an integer 42, otherwise it returns 0.
The task was quite daunting, but eventually yielded to an approach of breaking the problem down to smaller, achievable steps. We are very satisfied with what our team was able to accomplish. TDD was quite helpful in both testing the parser and in fleshing out the exact syntax of our Scheme-like language (initially it was more LISP like). The parser combinators in the Scala standard library made parsing a much simpler task, and the Scala type system and syntax helped a lot to represent the various compilation stages and their transitions.
When Apple introduced Apple Watch at September’s media event, it was clear that the company was betting everything on the success of the newest entry into the wearables category. While Apple is in no short-term danger—its new iPhones are still breaking sales records—the company had to prove it could innovate again in order to continue growing. After all, Apple had not introduced a new product category since the iPad, and more importantly, since the passing of Steve Jobs.
While it’s certain that Apple Watch will be an important driver for Apple’s future, the fact that Apple is placing such a big bet on the wearable category will have a hughely influential effect on technology as a whole. In fact, Apple Watch can be seen as a statement about what Apple thinks is the appropriate place for technology in our lives.
Wearables are a peculiar branch of technology. Indeed, the consensus seems to be that these devices are to be worn for much more than the functionality they offer, a fact that Apple seemed to have fully embraced with its new Watch.
In fact, Apple Watch is very different from other Apple products in many ways:
What also is surprising about Apple Watch, and a disappointment to many, is that Apple Watch doesn’t seem to bring any significant new technology, such as the multi-touch screen of the iPhone, into play. For me, however, this is an indicator that Apple believes the success of its wearable is not going to depend on technology alone, and what will ultimately matter is how well it integrates into the wearer’s life. Without having used the device, it’s hard to say if Apple has succeeded at this. So far, none of the other smartwatches I’ve tested have gotten this right.
If Apple Watch does become a success, there will be enormous opportunities for entrepreneurs and brands. Convincing users to install an app or accept push notifications on the prime real estate of wearers’ wrists will be a challenge worth taking. While it’s too early to reach conclusions about what will make a good Apple Watch app, imagining user experiences on Apple Watch will probably be very similar in difficulty to Google Glass.
Watch app makers will have to empathize with the wearers at an even more intimate level than in the mobile space if they want to offer worthy experiences. It is also unlikely that write-once-run-everywhere responsive web apps will make their way onto Apple Watch, at least without doing some work to make the experience watch-appropriate. This means that brands wishing to offer a multi-device experience will have to invest in adapting their services to the watch.
At a more fundamental level, if Apple Watch succeeds, it will be a testament to how far we are willing to immerse ourselves in technology. The psychological and cultural implications are hard to predict, but a mainstream Apple Watch may be our first step into a cyborg future.