Differences between revisions 11 and 12
Revision 11 as of 2011-05-07 19:13:03
Size: 3127
Editor: shoobe01
Comment:
Revision 12 as of 2011-05-07 23:03:29
Size: 4902
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:



An example of this cooperative design/development effort might work better than more explanation. All through the process of designing this eReading platform, development was in the room or around the corner. They understood, and approved of, the target state. The target was entirely modular. The IA diagram looked like this:

ILLUSTRATION - CORNER OF IA DIAGRAM, A FEW ELEMENTS AND THE LEGEND

Every view or state listed the elements within, and then the design specifications being built only focused on those re-usable elements, and the minimum amount of information needed to place them, and transition between states.

When the first iteration with UI came up we handed off just the wrapper, and the other few components needed to execute. Elements like this:

ILLUSTRATION OF SPEC FOR A CAROUSEL OR SOMETHING... maybe zoomed out so its not super clear, and you cannot read the text

And when the iteration was complete, and we all saw it demonstrated, it looked like this:

ILLUSTRATION - FINAL PLUS SOME PUI, TIMES ROMAN TEXT, BAD ALIGNMENT. POINT TO INCOMPLETE VS STATIC.

No, it's not all done. The developers bought into the target state so much they just took one of the comps and used it as a backdrop (this was built into the display engine for a demo, so took literally zero minutes). The real components are overlaid on top. And since they are components, that carousel is not just done on this page, but on about 15 pages. And since the design document clearly expressed the polymorphism, there appear to be three different types of carousel, though in fact it's the same one with minor conditional changes.

This is a much more efficient method in which to develop, and makes everyone on the team work hand in hand at every level.

This page is a stub. It's just something to get notes down, and is not final in any way.

...see the bottom. I have a presentation halfway done on this exactly...

How using the patterns can lead to better design by re-use consistency. If you pick a pattern, don't just pick it for the screen you are working on, but add to your documentation as a component that anyone can use on any part of the project. Communicate this to development. Then, only one of them is built, and used over and over. Consistent UX, as well as savings on development, QA, etc.

I think perhaps a bit about resolution-independent design, and otherwise class-based design. Can take any design, assign to a few size classes, input classes, etc. and generate from that.

And this needs to be in here somewhere, but here or another chapter or... something else:

Using these, and following patterns exclusively will result in what I am calling the heuristic solution. Which is fine, and will pass all the checkmarks and get decent test results, but is not going to be differentiable. Which might be fine for some applications, or some parts of an OS or app, but is not so useful for interfaces that must delight, or entice users to revisit. Simply using more gestures, for example, is not automatically delightful. You have to understand the product holistically, and think tangentially about the multiple ways to approach the solution. Note also that these patterns are generally not very prescriptive. Not that they don't require certain behaviors, and prohibit others, but read closer: There are options, and not objects to be implemented but principles upon which your object has to be designed. There's lots of room create something all new, and then divine the underlying truths of the design so pattern level principles can be applied to assure it still meets basic needs and is usable.

ALSO: maybe we should explicitly talk about design at this time. Like, a discussion of NUI being easily taken a step too far. -- If so, riff off this article http://globalmoxie.com/blog/evolution-of-touchscreen-discoverability.shtml And especially this paragraph which is a nice guideline -- added after my gripes :) "I don't mean to suggest that we throw out all of our familiar buttons entirely. Light switches shall remain necessary, after all, and so shall buttons, especially where it's necessary to trigger abstract actions ("share via Twitter," for example). But it's important to recognize those devices for what they are: necessary hacks for moments when direct interaction isn't possible. Touchscreen interfaces allow that direct interaction in many more contexts. As new solutions arise, we should be open to putting our time-tested workarounds aside. When designing an interaction for touch, always ask: do I really need another button or control for this?"

User-Centric Execution

...successfully building those designs, by leveraging patterns and heuristics...

An example of this cooperative design/development effort might work better than more explanation. All through the process of designing this eReading platform, development was in the room or around the corner. They understood, and approved of, the target state. The target was entirely modular. The IA diagram looked like this:

ILLUSTRATION - CORNER OF IA DIAGRAM, A FEW ELEMENTS AND THE LEGEND

Every view or state listed the elements within, and then the design specifications being built only focused on those re-usable elements, and the minimum amount of information needed to place them, and transition between states.

When the first iteration with UI came up we handed off just the wrapper, and the other few components needed to execute. Elements like this:

ILLUSTRATION OF SPEC FOR A CAROUSEL OR SOMETHING... maybe zoomed out so its not super clear, and you cannot read the text

And when the iteration was complete, and we all saw it demonstrated, it looked like this:

ILLUSTRATION - FINAL PLUS SOME PUI, TIMES ROMAN TEXT, BAD ALIGNMENT. POINT TO INCOMPLETE VS STATIC.

No, it's not all done. The developers bought into the target state so much they just took one of the comps and used it as a backdrop (this was built into the display engine for a demo, so took literally zero minutes). The real components are overlaid on top. And since they are components, that carousel is not just done on this page, but on about 15 pages. And since the design document clearly expressed the polymorphism, there appear to be three different types of carousel, though in fact it's the same one with minor conditional changes.

This is a much more efficient method in which to develop, and makes everyone on the team work hand in hand at every level.

Successfully Designing with Patterns and Heuristics (last edited 2013-04-08 20:02:22 by shoobe01)