Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

November 26 2013

11:00

Marvel: Free Website Prototyping Tool for Photoshop-Dropboxers


  

If you are anything like me, you fire up your Photoshop to create a first visual prototype of your next client’s website. And if you’re anything like me, you’re not bound to change that in the foreseeable future. All the clients I had over the last 20 years wanted to see a visual prototype before coding started. If you could create a clickable one, the better. A fresh web app named Marvel enters the stage with the promise to achieve just that. Are you a user of Photoshop, Fireworks, Gimp or any other pixel-editor and do you rely on Dropbox? Great, still, if you don’t design websites, you need not read further ;-)

April 27 2012

21:00

Beginner’s Guide to Wireframes and Tools to Create Them

This is the link to the original article creator of this site, if this message appears to another site than 1stwebdesigner - Graphic and Web Design Blog - 1stwebdesigner is a design blog dedicated to bloggers, freelancers, web-developers and designers. Topics focus on web design and inspirational articles. it has been stolen, please visit original source then!

Wireframing, or prototyping, while designing, costs almost nothing, but can give back so much. While many designers start with a sketch in their mind and then just put it into Photoshop or even code it right away, some others start on paper. Yes, paper, that (most of the time) white thing we write on with our hands. Sounds very 2000-ish, but even today the best designers out there use this technique to their advantage. Web prototyping saves lots of frustrations later on during the project development phase, as it makes sure there are no things to undo or redesign. If you prototype correctly, you can be sure about the fact that redesigning will never be something you will have to think of.

What wireframing basically means is putting your design ideas on paper – for each of the multiple pages of a website. All pages will probably share some elements, therefore the first one will be a bit more challenging to do, whereas the rest of them will be a bit less difficult as you already have a basic idea over the general design patterns.

Keep in mind that these common elements are a must for any design. When switching between pages the user will have to immediately recognize the fact that he is on the same site and not somewhere else. Always keep the navigation and the important sections (content, sidebar, footer) in the same place. But this tends to become a novice guide to web design, so let’s move on.

General – the wireframe

In order to be able to use a wireframe, you need to know how it actually works. What this does is simple – it illustrates the layout of a website and its main components on paper. You can use different shapes, such as boxes and ovals to draw content, navigation and other functional elements. You might ask yourself why do we use shapes? The answer is simple: because it allows us to focus more on the design and forget about coding, cross-browser compatibility, images and so on. It’s pure and basic design.

Image by Zach Hoeken.

Wireframing or Photoshop design?

The alternative to paper web prototyping is creating the visual design in Photoshop first. While it has advantages to some extent, creating the layout in Photoshop is not as effective because it does not allow you to focus on the basic design elements. If you start designing in Photoshop you will probably also start thinking about colors, images and fonts. There is no need for this if done on paper. And the process is way faster on paper as well, so why not go for it? You can obviously start designing in Photoshop at a later stage, but I wouldn’t recommend doing it before you have a clear idea of what you want to get out of the project. The only way to achieve this is to start on paper.

You can call a wireframe a sketch if you want to. As a matter of fact, a wireframe is a basic, simplified sketch of a website. It communicates some ideas to the client which he can accept or not. If he doesn’t, it is quite easy for you to take another sheet of paper and draw other ideas from the top. The main reason behind a wireframe is to let you focus on what is really important on a website: how each page looks, where the most important elements go and how to achieve the overall positive balance you need.

After you get the idea to the client and he accepts it, you are welcome to evolve the basic sketch into something more detailed. Now it is maybe time to start thinking of fonts, colors and images.

Image by Denkbeelhouwer.

The Prototyping Stage

It is crucially important for designers and clients to work together during this stage of the project. While a client doesn’t have too much to say during the coding phase, this is where he usually gives a lot of input you should consider. Remember that once he accepted the design, he will gladly give into your further ideas – at this point in time he already believes in you and your skills. It will be a tough and long project if you don’t get the acceptance on the basic wireframe from him.

If you are a client remember not to stress a lot about the lack of colors, images, fonts and other styles. The job of a designer for now is to give you a basic idea of what he thinks is good for you. If you ask for more detailed wireframes from him and reject them three or four times, it will cost you lots of money. On the other side, if you ask for basic wireframes and reject them, it won’t cost you as much, because they are easier to draw and think of.

Tools for web prototyping

Here is a list of some tools I recently tested in order to see how much designers can trust them in building wireframes. If paper is not good enough for you then, in any given order, here are the other possible solutions:

1. iPlotz

This tool allows you to create wireframes which you can click on and navigate through. This helps creating the experience of a real website. While you can get a free account on iPlotz, I recommend one of the premium ones if you are serious about starting with web prototypes from now on.

2. Balsamiq

If you like drawing, then this tool will give you the feeling of it, only now it is digital. The elements can be tweaked and rearranged easily and the control over them is quite easy as well. The results are clean and one of its advantage is that everything can be reiterated in real-time.

3. Pencil Project

This tool can easily be used to make diagrams and GUI prototyping.

4. templatr

Although it will not allow you to draw anything, this tool lets you create individual designs for your website on the go. You don’t need to know any HTML and you can download the template in the end with a single click.

5. Flair Builder

This is a tool capable of creating interactive wireframes very fast. It is quite easy to use and comes with a palette of functional components which will ease the process of creating prototypes. Flair Builder is also interactive and will improve your experience a lot.

Image by Michael Lancaster.

Bottom line

Wireframes, or web prototyping, is a process known to many designers, although just a handful of them use it. While it might seem that it takes a lot of time, on long-term it will help you a lot. If you know how to properly communicate and closely work with the client during prototyping, the rest of the project will go smoother than expected. I totally encourage you to prototype your designs before actually starting to code or to create the whole visual design in Photoshop. It will make the process easier for you and will spare you frustrations down the road.

Until next time, let’s spark some discussion here for my 50th article on 1WD. How often do you prototype your designs? How effective has it been for you? If you don’t do it, why is that?

January 05 2011

18:30

November 04 2010

14:20

October 21 2010

14:00

September 21 2010

18:55

September 01 2010

14:36

August 17 2010

14:42

June 14 2010

14:40

May 17 2010

08:09

Resurrecting User Interface Prototypes (Without Creating Zombies)

Smashing-magazine-advertisement in Resurrecting User Interface Prototypes (Without Creating Zombies)
 in Resurrecting User Interface Prototypes (Without Creating Zombies)  in Resurrecting User Interface Prototypes (Without Creating Zombies)  in Resurrecting User Interface Prototypes (Without Creating Zombies)

Every user interface designer is familiar with this procedure to some extent: creating a prototype and evaluating it with potential users to understand how the user interface should look and behave. Users will tell you what nags them and should therefore be improved before you code. So, at the beginning of any UI design process, you can expect your prototype to have to be modified in order to work.

Because you (and your client) want the changes to be as cost-efficient as possible, you are better off adopting change-friendly prototyping methods and tools. This is especially true in the early stages of the project, when your ideas for potential solutions are rather vague. In this early phase, most often you don’t even know the exact problem for which you are hunting for a solution. You are still analyzing more than designing.

To work change-friendly and cheap, then, it’s wise to start the prototype roughly (maybe as a paper sketch) and make it more sophisticated as you understand the requirements—that is, assessing what users will need (or what they won’t need) and how willing your client is to give it to them (yes, those are not always in line).

Finally, when the prototype has reached a certain level of expressiveness, it could even serve as a “living specification” for developers, to tell them how the front end should look and feel. These are sometimes referred to as high-fidelity prototypes. As soon as the developers know exactly what to code, your high-fidelity prototype can die in peace. It has no future… Or does it?

While this approach is plausible and indeed makes perfect sense for many situations, it needs to be slightly reconsidered in the context of new UI paradigms.

A New Challenge

Think of what is nowadays commonly called “natural” user interface (NUI). These fancy multi-touch (and similar) playgrounds are on their way to replacing (or at least augmenting) our good old graphical user interfaces (GUIs), just as GUIs replaced command line interfaces (CLIs), lowering the burden for users to interact with a system, because everything is now more direct than it was with a mouse and pointer.

UIs Become Natural… Well, Almost

With multi-touch apps, you just tap directly on what you want to manipulate or make a gesture on it, and there you go. NUIs are not solely about multi-touch either: a speech recognition system is a NUI, too. Just say what you want and the system will do it for you.

Let’s forget for a while that, though called “natural” user interfaces, they are still far from being truly natural. They just feel more natural than before. With multi-touch systems, most gestures are implicit, and you don’t get any convincing tactile feedback so far. Talking to a machine (like one with a speech-recognition system) can be pretty embarrassing. Nonetheless, NUIs are brilliant stuff and will conquer the world.

Image005 in Resurrecting User Interface Prototypes (Without Creating Zombies)

A Nightmare (to Come) for Developers

Unfortunately, what is brilliant for the user can be a nightmare for the developer. Admittedly, we are still ramping up the hype cycle (especially for multi-touch technologies), and yet programmers are already so fascinated by the possibilities that they are burning the midnight oil to get the job done. This enthusiasm won‘t last forever: NUIs will become common, as will their implementation. The problem that seems exclusive to developers is, in fact, a problem for UI designers, too: what’s hard to develop for the front end is also usually hard to design, prototype and specify.

Multi-touch UIs are especially delicate: so many nifty details influence the user experience that capturing them comprehensively takes a lot of effort. Which gesture will trigger which action? How many fingers should be needed to perform a particular gesture? How fast should the fingers move? How should a manipulated object or scene behave after a long time to keep up a proper cause-and-effect interplay?

Prototyping Becomes More Expensive…

As long as you concentrate your design efforts on a simple photo-sorting application, you won’t run into problems. You can easily prototype this experience by… well, sorting real photos. But multi-touch applications will become more complex, and gestures will occur in greater variety and (hopefully) help to solve more realistic problems. This gives the UI designer an unfamiliar challenge. Prototyping cheaply and, in the process, learning about the experience of solving a complex problem using gestures is almost impossible if there’s no suitable analogy in real life.

Of course, you could prototype parts and approximate a decent design, but then you would have that nagging feeling that you missed something and would doubt that you really translated what you intended. So, to design amazing interaction experiences for NUIs, you have to be prepared to rack your brain by performing more and smaller prototyping-feedback cycles. Creating an expressive prototype requires more time and expertise. Christopher Alexander has said:

Things that are good have a certain kind of structure. You can’t get that structure except dynamically. Period. In nature you’ve got continuous very-small-feedback-loop adaptation going on, which is why things get to be harmonious. That’s why they have the qualities we value. If it wasn’t for the time dimension, it wouldn’t happen. Yet here we are playing the major role creating the world, and we haven’t figured this out. That is a very serious matter.

As a building architect, Alexander has nothing to do with GUIs or NUIs. Still, his words are so universally true that they can be translated to the context of user interface architecture. The more natural and harmonious a UI designer wants a user interface to be, the more time and more iterations he will need to get there.

Good designers might require fewer iterations than poor designers, but they couldn’t do it without any (unless they made a one-to-one copy taken straight from nature itself). We can use simple deductive reasoning: good UI designs in the future will require more feedback loops; more feedback loops will make prototyping more expensive; and the more expensive prototyping is, the higher the burden of throwing a prototype away.

… Too Expensive to Throw Things Away

So, instead of throwing it away, what else can you do with your prototype? You could, of course, develop it over time, which means building on what you have and just adding or modifying the things that you’ve learned from feedback are missing or need to change. Even after development has finished, you can put the prototype on hold and get back to it later, as necessary. And let’s not deceive ourselves: even when you’ve gotten the requirements, the day will come when one of them will become invalid, at which point you will need to dig up your almost-forgotten creation to make changes.

But how effective is it really to evolve prototypes this way, and is the process enough to address the challenges that modern UI paradigms pose? To answer this, let’s look at what support a modern prototyping tool can give the UI designer. After all, not being able to do something with a prototyping tool may render the approach impractical. In the second part of this article, I’ll shed light on Expression Blend, because it now handles the widest set of possibilities we have faced so far for squeezing the most out of a prototype.

[Offtopic: By the way, did you know that Smashing Magazine has a mobile version? Try it out if you have an iPhone, Blackberry or another capable device.]

Prototype Recycling with Expression Blend

Let’s say you want to make use of Blend to design a NUI that is based on Silverlight or WPF and that lets you easily manipulate items on the screen. In the beginning, you wouldn’t even touch the tool at all; rather, you would “invent” whatever gesture you think is intuitive to perform this operation. Most likely, you would do this in your head or on a whiteboard. You’ll discuss and refine the design with teammates or potential users.

At this stage, everything is still low-fidelity, so throwing out things isn’t costly yet. When you have a good feeling about the rough design, you can start prototyping in higher fidelity, to be really sure that your idea works. To simulate the intended interaction experience, every single detail is critical in later prototyping stages.

CentigradeFacilityManagementPrototypeInBlend in Resurrecting User Interface Prototypes (Without Creating Zombies)

Defining Behaviors

First of all, defining how an item behaves during manipulation is interesting. In fact, Expression Blend allows you to attach such “behaviors” to an object, telling the object how to move, resize or do anything else according to a certain user input. The nice thing about behaviors is that they are self-contained software objects that you can use out of the box, without needing to know exactly how they work.

Because a growing community of developers already codes behaviors and publishes them on the Web free of charge, searching first for an existing behavior that approximates what you want to achieve is a good idea. In some cases, you may need to tweak the behavior to suit your needs; you do this either by yourself (if you’re one of those rare “designer/developers”) or by asking another developer for quick help.

Caring About Every Detail

Because you really want to engage users with your UI design, you may want to add stunning animation and other visual effects to the item being manipulated. Expression Blend offers a timeline for creating an animation storyboard, as well as a lot of properties to change the style of an item.

With animation, for example, an object that lethargically follows the path of your finger feels very different than one that organically accelerates and decelerates according to physical properties of the real world.

Everyone with an iPhone loves the “elastic strap resistance” behavior they get when scrolling through a list. To get such an immersive, engaging and to some extent natural experience, you have to perfectly coordinate all parameters, including location, speed, size, color, shape, etc.. Thus, you can elicit the precise emotional response in users that you’re aiming for only by composing, tweaking, testing usability, tweaking again, animating, styling, re-testing usability, modifying the styles, etc.

Usability testing, then, does not always need to happen a grand scale. Involving as few as two to three people can also yield quick valuable feedback. Still, you cannot do entirely without usability testing.

Getting Real

As soon as the prototype is finished, you will have to really implement it. Even though it took blood, sweat and tears to build it, it’s still just a prototype, after all, not a real application. You need the supports of developers to realize it.

So, how do you manage to implement the prototype while preserving all of the nifty details that you put together with painstaking effort? One way is to say to the developer:

Hey, could you please implement this part of the application exactly as shown in the prototype? It should behave exactly this way: same behavior, same animation speed, same visual style…”

You might possibly get the following answer:

What kind of an idiot do you think I am? You just want me to blindly rewrite what’s there? That isn’t challenging in any way. It just takes a lot of time. Go ask a monkey to do it.

ResurrectingUIPrototypes-ComicStrip-Strategy1 550px in Resurrecting User Interface Prototypes (Without Creating Zombies)
Large version

So, you may have to change your strategy:

Could you please take my stuff as is and incorporate it into the production environment? You don’t need to change anything. Everything behaves exactly as required.

To which the developer replies:

Are you crazy? This thing is cobbled together like Frankenstein’s monster. No way will I put this into a production environment. It will screw up the entire architecture.

ResurrectingUIPrototypes-ComicStrip-Strategy2 550px in Resurrecting User Interface Prototypes (Without Creating Zombies)
Large version

A big question mark might now magically appear over your head, because you cannot seem to get it right for the developer either way, and you don’t know why. Admittedly, we are exaggerating and simplifying here; if you are on a team, you wouldn’t put the request in yourself, nor would the developer be so offended by you. Still, the developer is justified both ways: he is right not to rewrite everything you’ve done, and he is right to worry about jeopardizing the system architecture. Here’s why.

Architecture, and Its Absence

Your prototype, as impressive as it looks and feels on the outside, has gone through several cycles and has accumulated a messy internal structure. It has copy-and-pasted spaghetti code from several community programmers, each of whom has a different level of expertise and follows a different coding convention (or worse, no convention at all). All kinds of software artifacts have been duplicated, thus violating the appropriately abbreviated “DIE” principle (“duplication is evil”). Also, the prototype would be memory-hungry and would perform poorly if it ran with real data. To summarize: the problem with your prototype’s inner architecture is that it has no inner architecture.

Yoder describes this kind of un-architecture as a big ball of mud, and that’s a good way to put it: adding a big ball of mud to clean stuff makes dirty stuff in result. Exactly the same thing happens when you hand over a big ball of mud for the developer to integrate into a cleanly organized architecture. Frankenstein’s monster is another apt analogy: if you try to keep your prototype alive as is, with body parts taken from different sources, at some point it will come around to bite you in the rear.

Preparing For The Recycling Process

So, how do you reincarnate your prototype as a living element in the production environment, instead of letting it die disgracefully or creating a zombie? Can this be achieved at all?

Quick Diversion: The Packaging Industry

To answer this, let’s look at the packaging industry. In the packaging industry, most waste is reused, for either the same or a different purpose. This is what we commonly call recycling. For this to work effectively, products are created from parts that consist of different materials or layers. A yogurt cup, for instance, is made of plastic, while the label may be cardboard.

So, after you’ve eaten your tasty dessert, each part finds its own way through the recycling process. Some of the materials are processed into new products, while others are thrown away. The key thing here is that the packaging industry separates a product into different components beforehand to be able to reuse as much as possible afterwards.

YogurtCup-Before in Resurrecting User Interface Prototypes (Without Creating Zombies)YogurtCup-After in Resurrecting User Interface Prototypes (Without Creating Zombies)

Now, how can this approach be adapted to UI prototyping and creating software? Borrowed wholesale, this would mean separating the prototype into several fragments during creation so that some of them can be used in the final system (either as they are or modified), while others are thrown out. Let’s see how Blend supports us here.

Back in Blend: Fundamental Concepts

If you use Expression Blend, splitting a UI prototype into different layers this way is easier than it sounds. Blend already has all of the bells and whistles to do it; for example, it has a bunch of clearly contoured and complementary concepts, such as control templates, behaviors, converters, styles, dependency properties, data bindings, triggers, etc. So, a control template would allow the designer to completely redefine a control’s visual elements without changing its fundamental behavior, while a behavior makes an object do things it would not do on its own, independent of how it looks.

This large set of orthogonal concepts was not created to annoy designers. It was designed to support them, by making their work more organized and formal and without restricting their creative freedom, which in turn allows for healthier collaboration between the designer and development team. After all, the development team has to get the job done in the end, or else the design team is doomed to languish on Prototype Island.

In fact, when you follow Blend’s concepts strictly, you create a number of artifacts that developers can reuse. Take a control template: a UI designer who does not want their UI to look standard will at some point have to create a control template. The good thing is that, because a control template is essentially about defining a UI’s visual elements, the designer can’t go wrong here: his job is to define visual elements. In turn, every single control template could likely be reused as is in the application. In other words, the “look” layer can be separated from the messy stuff below and therefore survive without causing any harm.

An Example: Why Use Value Converters?

For control templates, it is pretty clear why they can survive. Other concepts are not as clear but just as applicable. Let’s look at the concept of converters. A converter is a simple software class that takes one value and spits out another. What does this have to do with UI design?

A lot, because among other things, you will likely benefit from converters when you want cleanly formatted labels. As a practical example, think of email messages displayed in a table. Each row shows a single email message, with all its details, including subject, sender, date and time received, etc. For formatting, the date and time detail is the most interesting, as modern mail applications like Thunderbird and Apple Mail illustrate.

ThunderbirdDateFormat in Resurrecting User Interface Prototypes (Without Creating Zombies)

Thunderbird displays the date only for messages older than the current date, otherwise it just shows the time. Apple Mail displays “Today” instead of an absolute date if the email was received on the current date.

The intention is clear: get rid of any information that is not absolutely necessary. By doing so, you reinforce the important information by making it more scannable.

A good UI design is in the details. Converters can help improve how well a piece of information is detected and understood. Of course, you could just fill in the information “by hand”—in the case of our email example, typing “Today” in each cell as needed. But if you will have to evaluate alternative designs and formats with users, tweaking the converter is much quicker than manually typing uniquely formatted text in each cell. What’s more, just like behaviors, converters are self-contained, which will motivate community developers to write and share them with you, allowing you to use them out of the box.

Increasing Your Prototyping Speed

As you can see, by aligning the internal structure of the prototype with these different concepts, not only will you increase your prototyping speed in the long run, but you will end up with different parts that you can choose individually whether to throw away.

With converter, you may still encounter bad coding and naming conventions (which is sometimes the price of tapping community resources). In that case, you wouldn’t be able to use it because it would violate the internal structure of the final system. The good thing is, being a distinct concept, a converter is pretty agnostic in relation to the rest of the prototype, so you will have a clear idea of where to look to remove problems in the converter’s internal structure.

The converter itself, then, can be recycled instead of thrown away. And you can decide individually whether to reuse, recycle or throw away every distinct concept in your prototype.

The Recycling Process, Or “Rising From The Dead”

While the designer’s job when building a prototype is to follow Blend’s concepts, the developer’s job is to look after the recycling. But if you use the word “recycling” with a developer, he may look puzzled. In developer terms, this is actually called “refactoring.”

Refactoring: The Big Spring Clean

Refactoring means improving the internal structure of a system without changing its observable behavior. This is not voodoo magic. It just means that the developer has to change bad names to good names (while adhering to certain coding conventions) and that all of the duplications from your copy-and-paste orgies have to be centralized in a single location.

Renaming objects sounds tedious, but it’s not. Because the developer can open the same Expression Blend project that you worked on in Visual Studio, he can rename objects almost automatically without fear of breaking something.

Of course, the deeper the developer’s changes, the greater the risk of breaking something. This could lead to a good internal structure but a UI that does not look or behave as intended. An example of a deep change is centralizing duplicated code. Developers, though, especially those of the Extreme Programming school, have a way of avoiding such risks.

Avoid Risk With Test Cases

Developers would likely write some test cases before touching a prototype’s structure. A test case confirms a certain output or reaction whenever a certain input or interaction occurs. If it’s confirmed, the test case is considered a success; if not, it is considered a failure. The developer can tell exactly what output will result from what input just by using the prototype and discussing some of details with you (for example, determining what didn’t work as intended because you didn’t have the necessary time or skill).

Once the test cases are written and all of them have run successfully, the developer can begin the refactoring process. Whenever a fundamental refactoring step has finished, he will likely check the test cases again to see whether they still run successfully. If they don’t, he will need to undo his most recent changes and perform the step again. At the end of the process, if all of the test cases have run successfully, you will probably have a final application that has a clean internal structure and that looks and behaves as your prototype does. After refactoring, the prototype can be thrown away for good… but without shedding a tear, because every piece of it lives on in the final system.

And then the next time you have to make minor changes to your design (for example, because a requirement has changed), you will be working on the actual application, not the dead prototype. This allows you to benefit from everything the development team has done so far (such as performance optimization). Also, your and the developer’s work will not go out of sync, as would happen if your prototype and the actual system were being run simultaneously.

Although the refactoring process sounds complex and time-consuming, it is common practice in most development projects. Don’t be vain about it: the developer is not doing this just for you; he does it to keep the system maintainable and extensible.

Wrapping Up

To create a good user interface design, prototype your concepts and evaluate them with real users. The more natural you want the user interface to feel, the more details you will have to take care of. This makes prototyping more challenging and time-consuming than the conventional notion of prototyping, which is to “build something rapidly and cheaply.”

For this reason, some designers are tempted to simply turn their high-fidelity prototype into the actual system, as is. After all, throwing it away would be such a shame. But this approach is not advisable because it jeopardizes the system’s integrity, mainly because of the prototype’s messy internal structure, which arose as a result of the many changes that you implemented in response to user feedback.

Fortunately, modern prototyping tools such as Expression Blend allow you to create prototypes using different orthogonal concepts. They make it possible to split a prototype into parts and decide whether to throw out or keep each part individually.

For those parts that you cannot reuse as is, you can at least recycle or, to use the parlance, refactor them. Refactoring cleans up the messy structure of your prototype without changing its look and feel. The developer’s test cases ensure that everything is preserved as you intended.

So, if you are open to recycling prototypes, what are you left with? You get a user interface that looks and behaves exactly as intended, but that’s actually live. Also, you and the developer get to work on the same thing without conflicting with each other. Both of you do what you’re good at, and you generate something you can appreciate: you generate a nice UI, and the developer generates a clean system architecture.

And yet, all of this is possible only if your prototyping tool of choice supports it. It’s not always about “people over tools.” Sometimes it’s the other way around: pick the right tools, use them correctly and then see how people from different disciplines gel as a team.

Further Reading

  • Effective Prototyping
    The website to accompany the book Effective Prototyping for Software Makers by Jonathan Arnowitz, Michael Arent and Nevin Berger. The book provides broad and useful information on prototyping in general.
  • User Interface Prototypes in Usability Engineering
    A blog article on the process of creating prototypes in the early stages of a project.
  • Hands-on Natural User Interfaces
    The website for the book Multitouch on Windows: NUI Development with WPF and Silverlight by Joshua Blake. The book is not finished yet but looks promising.
  • Designing Gestural Interfaces
    The website for the book of the same name by Dan Saffer.
  • Big Ball of Mud
    A brilliant article on architecture and evolution, by Brian Foote and Joseph Yoder.
  • How Buildings Learn
    The Wikipedia entry for Steward Brand’s book.
  • Refactoring
    The Wikipedia page on the meaning and purpose of (code) refactoring. As for books on the topic, Martin Fowler’s Refactoring: Improving the Design of Existing Code is highly recommended.
  • Extreme Programming
    Explains extreme programming (XP).
  • The New Iteration
    The subtitle of this book by Karsten Januszewski and Jaime Rodriguez is “How XAML transforms the collaboration between developers and designers in Windows Presentation Foundation (WPF).”
  • Electric Beach
    The website of Christian Schormann, product manager of Expression Blend.
  • Modern User Interface Design Tools
    A blog article comparing Microsoft Expression Blend and Adobe Flex Builder.

(al)


© Thomas Immich for Smashing Magazine, 2010. | Permalink | 2 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: interface, prototype, prototyping, ui, user

April 30 2010

15:47

Want Web games on all things iTouch? Scripty 2.

Thomas Fuchs has a detailed post on building a Flash-y game with scripty2 where he walks through a memory game.

Everything is shown, from game logic all the way to the smooth animations and easings:

JAVASCRIPT:
  1.  
  2. // animate cards to go to new positions
  3. cards.inGroupsOf(4).each(function(group, x) {
  4.   group.each( function(card, y){
  5.     flip(card, 'back.png');
  6.     card.morph('opacity:1;left:'+(x*SIZE)+'px;top:'+(y*SIZE)+'px', {
  7.       duration: duration || 0.5, transition: 'easeInOutQuint'
  8.     });
  9.   });
  10. });
  11.  
  12. // flip card animation
  13. function flip(element, image){
  14.   var img = element.down('img');
  15.   img.morph('width:0px;left:70px;', {
  16.     duration: .2, transition: 'easeInCubic',
  17.     after: function(){
  18.       if(image) img.src = image;
  19.       img.morph('width:140px;left:0px', {
  20.         duration: .2, transition: 'easeOutCubic'
  21.       });
  22.     }
  23.   });
  24. }
  25.  

Very detailed indeed.... awesome.

April 05 2010

18:34

Prototype 1.7 RC Sizzles…

Andrew Dupont and the the Prototype team have announced the first RC of Prototype 1.7 which changes the selector engine to Sizzle, a new event API, has new layout/dimensions API, and more.

Element#on

Element#on is a new way to access the Prototype event API. It provides first-class support for event delegation and simplifies event handler removal.

E.g.

JAVASCRIPT:
  1.  
  2. $("messages").on("click", function(event) {
  3.   // simple version
  4. });
  5.  
  6. // can also pass in a selector which means
  7. $("messages").on("click", "a.comment_link", function(event, element) {
  8.   // ...
  9. });
  10.  
  11. // instead of
  12. $("messages").observe("click", function(event) {
  13.   var element = event.findElement("a.comment_link");
  14.   if (element) {
  15.     // ...
  16.   }
  17. });
  18.  

Element.Layout

The second major feature in 1.7 is Element.Layout, a class for pixel-perfect measurement of element dimensions and offsets.

Now you don't have to decide between properties like offsetWidth (which return numbers, but not the numbers you want) or retrieving computed styles (which have their own set of quirks and require a call to parseInt).

JAVASCRIPT:
  1.  
  2. // Simple case
  3. $('troz').measure('width'); //-> 150
  4. $('troz').measure('border-top'); //-> 5
  5. // Offsets, too:
  6. $('troz').measure('top'); //-> 226
  7.  
  8. // More complex case
  9. var layout = $('troz').getLayout();
  10. layout.get('width')//-> 150
  11. layout.get('height'); //-> 500
  12.  
  13. layout.get('padding-left')//-> 10
  14. layout.get('margin-left');   //-> 25
  15. layout.get('border-top');    //-> 5
  16. layout.get('border-bottom'); //-> 5
  17.  
  18. layout.get('padding-box-width'); //-> 170
  19. layout.get('border-box-height'); //-> 510
  20.  

Other fixes

The JSON interface slated for ECMAScript 5 is already being implemented in major browsers. It uses many of the same method names as Prototype's existing JSON implementation, but with different behavior, so we rewrote ours to be ES5-compliant and to fall back to the native JSON support where possible. A few other methods, like Object.keys, received similar treatment.

November 25 2009

11:05

CBC Radio 3 Case Study

Phil Rabin of CBC Radio 3 has kindly written a guest post on his experience creating a fantastic Web interface for the station that uses Flash for audio, but a full HTML experience that maintains state from page to page.

cbcradio3

CBC Radio 3 is a community, radio station and user-generated independent music library which is a small department of the Canadian Broadcasting Corporation. When the CBC Radio 3 web team was called upon to rebuild the site we were confronted with the technical problem of having an uninterrupted music experience for our users. The old design of the site (see image) achieved this by embedding a flash player in the body with the content being served through a statically positioned iframe in the center of the page. Radio 3's content offerings were outgrowing the design so we went with a full page 1000px-wide layout with the player resting in the page. This created an obvious hurdle being that with a fresh page load comes a bad listening experience like myspace where a single wrong click breaks the audio. Also, not having popup player was a design decision that was made to give the website a more integrated feel.

We decided to completely removed flash from the UI equation and went full html/ajax because we found that it offered more flexibility and play with the page. The hardest part was figuring out a way to maintain state on each page load while keeping the audio continuous.

We went with an old-school frameset to create a type of inter-frame communication with the top level frameset acting as the orchestrator/bootstrapper. The visible "UI Controller" frame is completely blown out with the stateful player frame hidden from view.

The stateful player frame contains hidden swfs to handle playing audio and connecting to RTMP for our live streaming. All the communication in and out of flash is handled by a couple gateway javascript classes to abstract out the flash from the rest of the application.

Here's an example of a communication gateway for wrapping the events coming to and from flash. The event objects are native flash event objects that get sent by Flash's ExternalInterface and come in as JSON that can:

JAVASCRIPT:
  1.  
  2. CBCR3.namespace("CBCR3.Player.External");
  3.  
  4. CBCR3.Player.External.RTMPGateway = Class.create(CBCR3.Commons.EventDispatcher, {
  5.      
  6.     initialize:function($super)
  7.     {
  8.         $super();         
  9.     },
  10.      
  11.     //Functions to receive events from flash   
  12.     sendStreamEvent:function(event)
  13.     {
  14.         this.dispatchEvent(event.type);
  15.     },
  16.    
  17.     sendMetaDataEvent:function(event)
  18.     {         
  19.         var metaData = new CBCR3.Player.Mappers.StreamMetaDataDtoMapper().mapCollection(event.metaData);       
  20.         this.dispatchEvent(CBCR3.Player.Events.RTMPStreamEvent.metaDataReceived, {metaData:metaData});
  21.     },
  22.        
  23.     //Functions to send commands from flash
  24.     sendStreamCommand:function(commandName, commandArgs)
  25.     {         
  26.         $(CBCR3.Player.Globals.rtmpPlayerId).streamCommand(commandName, commandArgs);
  27.     }
  28. });
  29.  

A single instance of this gateway is always maintained in the application which is called by a sort of simple container like this:

JAVASCRIPT:
  1.  
  2. ExternalInterface.call("CBCR3.Player.Application.IoC.getInstanceOf('rtmpGateway').sendStreamEvent", event);   
  3.  

An instance of the gateway has to be maintained by the player application because events coming from flash have no context. This way the application classes can subscribe to events coming from flash like this:

JAVASCRIPT:
  1.  
  2. CBCR3.Player.Players.RTMPPlayer = Class.create(CBCR3.Commons.EventDispatcher, {
  3.     initialize:function($super, rtmpGateway, thumbLookupService)
  4.     {
  5.         $super();     
  6.          
  7.         this.rtmpGateway = rtmpGateway;       
  8.  
  9.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.metaDataReceived, this.rtmpMetaDataReceivedHandler.bind(this));         
  10.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.ready, this.streamReadyHandler.bind(this));
  11.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.connecting, this.streamConnectingHandler.bind(this));
  12.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.streaming, this.streamStreamingHandler.bind(this));
  13.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.connected, this.streamConnectedHandler.bind(this));
  14.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.metaDataConnected, this.rtmpMetaDataConnectedHandler.bind(this));
  15.         this.rtmpGateway.addEventListener(CBCR3.Player.Events.RTMPStreamEvent.failed, this.rtmpMetaDataFailedHandler.bind(this));
  16.  
  17.  
  18.     },
  19.  
  20.     streamReadyHandler:function(event)
  21.     {
  22.         //handle stream event
  23.     },
  24.  
  25.     streamConnectingHandler:function(event)
  26.     {         
  27.         //handle connecting event
  28.     },
  29.  
  30.     streamConnectedHandler:function(event)
  31.     {
  32.         //handle connected event
  33.     },
  34.  
  35.     rtmpMetaDataConnectedHandler:function(event)
  36.     {
  37.        //handle meta deta connected event
  38.     },
  39.  
  40.     rtmpMetaDataReceivedHandler:function(event)
  41.     {         
  42.         //handle meta data event etc etc
  43.     }
  44. );
  45.  

At the core, audio is always played by Flash. The swfs broadcast events, such as audio head position and download progress of mp3s, and connection, streaming, meta data events from RTMP. Those events get passed on the instance of the hidden stateful player.

Since the server frame is only loaded once when the site first loads, an instance of the stateful server player is instantiated for the entire session on the site. On each client frame page load, the server player instance is "injected" into the visible client UI controller by the "bootstrapper" top frame. State is maintained in that instance which allows for the controller to query the state of that object and reestablish everything like which track is playing, progress, time, thumbs up or down status, shuffle, play mode (stream or individual mp3 and playlists), etc. Everything had to be covered like if an mp3 was in mid-load when someone browsed to a new page, the loading progress had to pickup on the next page. Here's a example of the bootstrapper code contained in the frameset:

JAVASCRIPT:
  1.  
  2. CBCR3.namespace("CBCR3.Player.Application");
  3.  
  4. CBCR3.Player.Application.R3PlayerBootStrap = Class.create({
  5.  
  6.     serverFrame:null,
  7.     clientFrame:null,
  8.  
  9.     autoStart:true,
  10.     permalink:null,
  11.  
  12.     initialize:function(preferences)
  13.     {         
  14.         this.autoStart = preferences.autoStart;
  15.         this.permalink = preferences.permalink;         
  16.     },
  17.      
  18.     setServerFrame:function(serverFrame) {
  19.         this.serverFrame = serverFrame;
  20.     },     
  21.          
  22.     setClientFrame:function(clientFrame) {
  23.         this.clientFrame = clientFrame;         
  24.     },
  25.      
  26.      
  27.     //TRY LOAD PLAYER
  28.     loadPlayer:function()
  29.     {         
  30.         if(!this.clientFrame || !this.serverFrame)
  31.             return;
  32.  
  33.         //both frames are loaded at this point
  34.         if(this.serverFrame.getPlayerInstance() == null)
  35.             this.initializePlayer();
  36.         else
  37.             this.resumePlayer();
  38.     },
  39.      
  40.     initializePlayer:function()
  41.     {
  42.         this.serverFrame.initPlayer();
  43.  
  44.         this.clientFrame.checkEnvironment();
  45.         var masterPlayerInstance = this.serverFrame.getPlayerInstance();
  46.         this.clientFrame.loadPlayer(masterPlayerInstance);
  47.         masterPlayerInstance.addEventListener("stateInitEvent:streamPlayerLoaded", this.streamPlayerLoadedHandler.bind(this));
  48.         masterPlayerInstance.addEventListener("stateInitEvent:playlistPlayerLoaded", this.playlistPlayerLoadedHandler.bind(this));
  49.     },
  50.      
  51.     resumePlayer:function()
  52.     {
  53.         this.clientFrame.loadPlayer(this.serverFrame.getPlayerInstance());
  54.         this.clientFrame.resumePlayer();         
  55.     },
  56.      
  57.     streamPlayerLoadedHandler:function(event)
  58.     {
  59.         if(this.autoStart && this.permalink.include("/stream/"))
  60.             this.clientFrame.getPlayerInstance().stream(this.permalink);
  61.     },
  62.      
  63.     playlistPlayerLoadedHandler: function(event)
  64.     {
  65.         if(this.autoStart && this.permalink.include("/play/"))
  66.             this.clientFrame.getPlayerInstance().playlist(this.permalink);
  67.     }
  68. });
  69.  

We used Prototype/Scriptaculous as the base for the entire site. All the AJAX communication is handled with asp.net web services with scripting enabled. ASP.NET takes care of all the serialization of DTO's (Data Transfer Object) into JSON which are specific to the player application.

All of the classes in the application are written using Prototype's Class/inheritance model. Most of the classes subclass from a base EventDispatcher much like AS3, which is adapted from Matthew Foster's example for Prototype and our own custom Event model. This allows for a nice separation of concerns and decoupled classes throughout the application and allows the UI Controller to add event listeners to custom events coming from the server player instance.

JAVASCRIPT:
  1.  
  2. CBCR3.namespace("CBCR3.Commons");
  3.  
  4. CBCR3.Commons.EventDispatcher = Class.create({
  5.      
  6.     buildListenerChain:function()
  7.     {
  8.          
  9.         if(!this.listenerChain)
  10.             this.listenerChain = {};                                   
  11.      
  12.     },
  13.      
  14.     addEventListener:function(type, listener){
  15.                                    
  16.         if(!listener instanceof Function)
  17.             alert("Listener isn't a function");
  18.              
  19.         this.buildListenerChain();
  20.                  
  21.         if(!this.listenerChain[type])                         
  22.             this.listenerChain[type] = [listener];
  23.         else
  24.             this.listenerChain[type].push(listener);
  25.          
  26.     },
  27.          
  28.     hasEventListener:function(type)
  29.     {
  30.         return (typeof this.listenerChain[type] != "undefined");
  31.     },
  32.      
  33.     removeEventListener:function(type, listener)
  34.     {
  35.         if(!this.hasEventListener(type))
  36.         return false;
  37.      
  38.         for(var i = 0; i <this.listenerChain[type].length; i++)
  39.             if(this.listenerChain[type][i] == listener)
  40.                 this.listenerChain.splice(i, 1);
  41.      
  42.     },
  43.      
  44.     clearEventListeners:function()
  45.     {
  46.         this.listenerChain = {};
  47.     },
  48.      
  49.     dispatchEvent:function(type, data, target)
  50.     {         
  51.         var    event = new CBCR3.Commons.Event(type, data, target || this);
  52.         this.buildListenerChain();
  53.      
  54.         if(!this.hasEventListener(type))
  55.             return false;
  56.      
  57.         this.listenerChain[type].any(function(funct){
  58.             return (funct(event) == false ? true : false);
  59.         });
  60.     }
  61. });
  62.  

This also allows the UI Controller to unsubscribe from all events when the page unloads. This was key in memory management and so that we don't get orphaned references to instances of the UI Controller.

The most difficult part of the whole player project was re-establishing state of the controller on every page load. We hoped that we could implement some sort of state-pattern with no luck. In the end, the UI controller contains a couple monster resume methods that we haven't been able to abstract out of that class. We'd like to bring in some sort of MVC architecture that wires up the UI player view to a state object. Any suggestions would be welcome! Go check out the site and give us some feedback!

Dion: I then asked Phil about the CBCR3 library and he replied

CBCR3 is the base namespace for all th javascript controls and apps written for the site. Everything for the player is in CBCR3.Player, the concert calendar is CBCR3.Gigs, etc. We have a shared base lib which is in CBCR3.Commons.

An issue with Prototype that we had was some bug with including 1.6.1 in a frameset in Opera. So, right now the frameset is holding an older version of prototype while the frames have the latest. One thing that Prototype was seriously lacking was Date extensions. (like addDay, addMonth, addWeek) etc.
We ended up going with YUI's DateMath widget for that which really smoothed out working with dates.

Most of the issues we had cross-browser stuff was with IE6 (no surprise), which were almost all related to CSS rendering bugs, and IE DOM manipulation problems. A big one was upon the dynamic removal of items from lists. IE has a real hard time refreshing the positions of items. We had to write methods like

JAVASCRIPT:
  1.  
  2. myList.select("li").each( function(item){
  3.    li.setStyle({display:"none"});
  4.    li.setStyle({display:"block"});
  5. });
  6.  

this would in effect "nudge" the browser and force it to update the position of the remaining DOM elements. In the end, we chose to drop IE6 support and to tell you the truth, we haven't heard a single complaint about it!

November 10 2009

19:15
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl