Responsive principles
âąAls PPTX, PDF herunterladenâą
5 gefĂ€llt mirâą1,868 views
Presented at Float Mobile eLearning Symposium, at Chicago TechWeek, on 25 July 2012. Buzzwords and trends in design, development and process hold much weight in our industries, and foster much arguing and staking out of opposite positions. But more of these are in fundamental agreement than is generally acknowledged, and merging approaches, much like collaborating with a varied team, can yield the most useful results.Steven will discuss the underlying principles of responsive & fluid design, progressive enhancement, adaptive design, device detection, multi-platform design, cross-platform development processes, and mobile device capabilities. He will present one possible unifying theory of how you can not just develop the shiniest iOS app, but design the best experience for your users, on every screen and with every interaction.
Empfohlen
Weitere Àhnliche Inhalte
Ăhnlich wie Responsive principles
Ăhnlich wie Responsive principles (20)
Mehr von Steven Hoober
Mehr von Steven Hoober (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
Responsive principles
- 1. Responsive Principles More than designing for size @shoobe01 #float2012 1
- 2. Learn by typing, talking, and sharing. 2
- 3. Select a platform first, right? 3
- 4. Lies, damned lies, and statistics. 4
- 7. Design for every platform, and every screen. 7
- 10. But thatâs okay. 10
- 11. Device detection and server-side software. 11
- 12. RESS isnât new, either. 12
- 13. But itâs a convenient acronym. 13
- 14. 14
- 15. Design beyond pixels. 15
- 16. Percent? Em? Point, pica, mm, inch, twip. 16
- 17. Design for the real world. 17
- 18. 18
- 19. 19
- 20. 20
- 21. 21
- 22. 22
- 23. Respond to more than scale. 23
- 24. 24
- 25. Principles > Patterns > Templates > Pages 25
- 26. Features != pages 26
- 27. 27
- 28. Design for every screen. 28
- 29. Then design for each screen. 29
- 30. Enhance for each platform. 30
- 31. Stick to your principles. 31
- 32. Design to make decisions. 32
- 33. Products, not platforms. 33
- 34. Customers, not users. 34
- 35. Is it still any good? 35
- 36. Is it still the right thing to make? 36
- 37. Then change your principles. 37
- 38. Execute for every screen. 38
- 39. Data and services first. 39
- 40. Build for the future. 40
- 41. Layers and planning. 41
- 42. Do everything once. 42
- 43. Platform teams should borrow and cheat. 43
- 44. Yes. 44
- 45. 45
- 46. Donât copy that last chart. 46
- 47. Actually, donât copy anything Iâve done. 47
- 51. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 51
Hinweis der Redaktion
- 2 iTouchesTouch StencilOther RulersHotel bill
- I think of presentations, or blog entries, in much the same way I consider taking notes in a class or while watching a presentation. The very act of writing down your thoughts or perceptions causes you to evaluate, and codify them, and come up with new relationships and better information. Actually, my design process as a whole is built on principles like this as well.Every presentation I give, even if broadly speaking to the same topic, is custom built. Not just to give you the most bang for your buck, but because I can't stop myself. Simply practicing the presentation reminds me of dozens of things I need to revise, or a new direction to take it. Going to conferences just makes it worse, as I see how many other presentations are related, and interesting, and my brain starts spinning. Oh, if only I could be assured of the absolute truth of my ideals and just keep saying the same thing in blissful ignorance.Lately, I've been talking about a few basic topics:Always, design for every screen Lately, really using your device capabilities As well as some thoughts on integrating development and UX processes to get the right outcome
- Before I get too far along, let me explain some of the basic reasons I am going to talk about design and development choices: Because you probably want people to buy and use your products. Maybe even for a long time. Maybe tell their friends. When you sit down and decide to start building for mobile, the first thing you probably say is stuff like, âwhich platform do I launch on first?âI have to give this answer quite a bit, in some detail. Iâll skip most of the detail for now, but the short answer usually is: A website. For mobile AND desktop.Briefly: because it offers universal access; As method of discovery, and linking it provide a gateway to other products; Thereâs no barrier to publishing updates, so you can fix and revise easily; And most important to me, analytics. You get great data on who is using the site, and how.
- But what website? There are so many screen sizes, and so many devices. What if I just build for mobile Safari? I have one. Everyone I know has one. Must be fine. Anyway, itâs easy. All iOS devices are the same. And that damned Android is /confusing/, what what the âfragmentation.â [Hold up both of my itouch devices] â These are both perfectly functional iPod Touches. I use them for test a lot. Why do I have two? Because this one only runs iOS 3.2. No better. TWO MAJOR VERSIONS behind the current, and three behind what a lot of us have. Lies and âstatistical truthâ (but distort the reality of a situation) about say, how fragmented Android OS adoption is compared to iOS, do not help. Not just in a journalistic integrity manner, but they make you believe lies about the world which make you take unproductive courses of action. So if you build a website first, but draw in ios templates, and code for mobile safari, take one guess why you get mostly iOS visitors.
- Of the last dozen or so apps I have worked on, exactly 1 has been targeted first to iOS. Not because the team all carries Android, and wanted to be contrarian, but because they looked at the actual stats. They look at analytics from the existing products, or launch on the web first. They check market share in the region and for the audience they are launching in. And, let me be clear, this is out there: almost never do I have to push for this. Business owners are starting to get the idea of serving the customer, and making informed decisions based on real evidence. Platforms like Android and Windows Phone (of all things) are growing in development-manager mindshare. If you design based on perception, love, religion, or hear-say⊠if you build for one platform then expect to just sort of stretch to fit others, you are just missing opportunities.
- And, letâs be clear about why this matters. Forget rates of use of alternative OSs. I wonât even mention that half the smartphones in the world run Symbian. Or that Blackberry still sells well in many markets. No, instead, Iâll ask: Who thinks ubiquitous computing is more or less here? Essentially everyone in the world, in the next decade or two â everyone in the WORLD â is going to have access to a network connected device. Forget the question of whether itâll be an iPhone. Will it even be a handset sized device? Will it be touch? Will it be /portable/? I have been working this past week on a product related to smartphone users in Africa â they donât have many now, so itâs early and weâre working on the future. One platform weâre building for: desktop PCs. As the continent becomes more connected, some of the people with smartphone purchasing power will be information workers. They will start having computers at their desks.Probably.
- But I donât much care if I am wrong. Because I am using things like connected TVs, kids with connected portable game consoles, or even just desktops for the developing worldâs new information workers, as stakes in the ground. Something to gather the ideas and get basic behaviors.The design itself of any product has to start at a much higher level. More WHY it is needed than HOW. You have to get to the user tasks, agnostic of technology, much less platforms. When you consider interfaces, you have to include voice, and sms, and posters and what is outside the system, so gets written on Post-Its.
- You conceptualize the design so data and software are the same regardless of platform, so weâre talking about Responsive design, right?
- First, itâs good to know where things come from. Responsive design is just a term invented recently by Ethan Marcotte, to encompass some current trends. It reminded me right away of Fluid design from a few years back.But then I cast my mind back, and remember thinking the same thing in that era -- when CSS ZenGarden became big; that this was cool stuff, but not conceptually different than what weâd been doing for years. We did percentage tables, and framesets (god help us) from around 1997, in ways that are very, very similar to what is going on today with multi-screen design. As soon as CSS came around, we scaled type, and used background images in weird ways to account for multiple screen sizes. Hell, I applied for a patent on a funny button made of tables and styles, so we could feed it from datastores, and it would resize depending on the content and interface. Not granted, but we used stuff like this for years.
- I do get a little annoyed by those who promote these ideas as brand new (or more, by the people who buy it), but even when itâs a hyped trend, many of these are just fine trends. They communicate good principles. As long as we get away from one-size, pixel-perfect designs. Which⊠isnât /quite/ happening. The new Dreamweaver, for example, has this very rigid framework where you pick a few sizes to be responsive to. Ennnnh. Not right, but okay. Better than it was.The other problem of course, is they are so very focused on the client side.
- Especially for mobile, this is awful. You cannot send giant images and scads of javacript over to make it fit a featurephone screen. It wonât even bother to render. But if you use device detection, a tool like WURFL, and let it send the right content to the client, this solves everything, with much the same principles of design. Your same device classes can even work, you just push the intelligence back a layer, and make it more reliable.
- Wait, that sounds familiar. Yes, RESS is this concept, also with a new name.
- Buzzwords do their job. Trying to explain device detection was a total uphill battle until quite recently. RESS is one of those buzzwords thatâs starting to work. Itâs being treated a bit like early Ajax, where everyone is trying to copy the implementation. But eventually weâll get to principles.
- So, weâre going to design to lots of different sizes. This is real. Just the new Android devices from the first quarter of this year or something. With no repeats. This is not pixel dimensions, but actual sizes. Note the different aspect ratios. And double this, as they all flip to landscape. Quadruple it when you get to TVs, and add in a few more OSs.Wait, did I just say screen size? What about the resolution?
- Who cares? Your finger cannot be measured in pixels. I have no rulers graduated in pixels. My eyeballs, much to your surprise, see photons, not pixels. Once you get past the wonderment of your sharp display, it doesnât matter. What matters is physical size, and distance from the device. For viewing. For touch, just size. This is so important, I have stopped carrying random rulers, and recently made up a tool just for measuring things like touch targets on mobiles. [Hold it up] (Buy the template I am referring to here http://4ourth.com/wiki/4ourth%20Mobile%20Touch%20Template)
- Physical sizes: Em is great, but (âyou say it âe mâ but itâs âemâ) but it needs a baseline. Do not specify that in px, but in pt, mm, twips, in or anything else you want. As long as itâs a physical size. Device independent pixels, are /okay/, but just okay. Itâs, conceptually, philosophically, a cheat for the reality-challenged. Every OS Iâve worked on supports physical sizes also at some level. Iâd try to use those. Skip the cheats and automatic scaling. iOS defines things in pixels, then scales to double that. But I cannot tell why except for laziness, or that theyâd have to admit the world is more complex.
- Set aside your pixels. Design for people. Design for real sizes, in the real world.
- And design your features for the way people use, and expect to use their products. This is a pretty typical chunk of an IA document. Thereâs a requirement for email in the mobile app, so we put in an email page. And a confirmation page. And so on. Easy.
- But smartphones have email. Sure, desktops do to, but they are stupid. They forget who you are, launch the wrong email client. Forget context and cannot pass much info.
- Mobiles are mostly pretty smart. They remember you. They pass this state between services. You donât even always have to code in what the action is precisely, email or sms. You can just put a âshareâ icon into your app. Sometimes, into your website.
- And then the user gets to pick, sometimes, depending on the platform, what they want to do with the information.
- So, you can meet that same feature, with a lot less code, a lot less to test and go wrong, and you can better meet their expectations. Hell, you can drop maps and directions, and local weather, and offer links to other products on the appstore and⊠lots of things.
- The responsive principle is still solid, especially when you use RESS and device detection to load the right content from the server.
- Believe in mobile. It has all these capabilities, this intelligence and contextual awareness. Use these.
- So, that seems obvious. Why isnât everyone doing it? Thestate of responsive design (and the related concept)today is at the page or template level. Maybe, if lucky at patterns.We need to move the discussion to principles; to design architectural solutions for each platform. Because we need to extend these principles to items that are not just served up at the moment, but to the way we design and build packaged products: applications.
- What that means is that you need to step back from your process. Web design made us all lazy, and states donât exist anymore. Itâs all pages. To the point that itâs hard to find a quick-and-easy prototype tool that supports something as simple as a popup, or accordion. And so⊠apps get developed that are nothing but pages swiping to other pages.
- Where did all these cards come from? Well, they are features. And guess what happened on this project? The default answer. The same as happens on all the projects I work on. This was assumed (estimated, planned) that each card = 1 page. I spent a lot of time fighting to explain that itâs a webapp. That my storage and organization tool is ONE PAGE, and a few popups. And a lot, a lot, a lot of state changes. (When the mobile app team got ahold of it, they made it with lots of page transitions. Hmm.) So, how did we get here? How do we know every one of these features is good and useful, or the most important ones are being done first?
- We donât. At first. Just put it all out there. If itâs a likely feature, and technically possible ON ANY PLATFORM, put it up. Then perform normal UX evaluation processes to determine what features are needed, and draw out processes where the user walks through the system, to determine the relationship between features, across ALL platforms.
- When you start to branch the design to platforms, interesting things happen. And they arenât all about reducing the content for mobile. They are about using the capabilities I just discussed a few minutes ago. Itâs common to say that mobile is limited, compared to desktop, because itâs smaller, harder to type on, and so on. I like to say mobile is better, because of the sensors, and some general focus on the user and identity and network connectivity. But letâs say instead: every platform has itâs strengths.
- If so, some of the buzzword-worthy principles fall by the wayside. You cannot consider graceful degradation, or progressive enhancement to be true. Except in very specific domains. Does it support /this particular javascript function/?When you are considering how to fulfill the features needed on each platform, in their most native way, itâs hard to say one is better, or worse. Or that one is a degraded experience. You can not enhance progressively, moving up the platform chain, but provide enhancements to each platform in turn.
- When you start considering features this generally, at this high a level, there is a risk of feature creep. You have to make solid decisions of what to keep, what can wait till the next release, what is simply not core to the product. You cannot do this off the cuff, or by looking at screenshots, much less cards on the wall. You need to make sure, early on, the project had measurable goals, a known audience, and design objectives to reach these goals and needs. Refer back to these, when itâs time to scope or scale.
- But how do you decide big issues, like what platforms are first? It might not be such a simple decision as âweb, then OS-that-visits-the-most.â This is, often, an âorganicâ decision. The design itself should lead you. I am working on one right now thatâs a very simple example. Itâs got no web interface. Because itâs about being used places like down a mineshaft. Seriously. Network connection at the moment of use doesnât matter, so local storage rules the day. So, itâs a CD, a paper catalog, a desktop website, and a mobile app. Only. And as it turns out, we canât make these decisions without some design. We canât do them at the corporate planning team level, at the finance level, at the steering committee. The ITPM, and technical architects canât make it. If you need to build products for your company, and your users, the driving force has to be making it useful for them.
- I keep saying âproducts,â so if you donât think of what you do as a saleable item (perhaps for good reason), let me explain.This is very much the difference between say a âprogramâ and a âproject.â I am here using âproductâ to mean a conglomeration of âplatformâ solutions.
- This is in the same way some people use âcustomerâ instead of âusers.â I am one. And actually, I tend to draw a distinction between âcustomer,â and âprospect,â meaning a prospective customer.This is not all because weâre cynical money-grubbers, but because â whether or not you charge money for your app or site or service -- if it doesnât work like a commercial product, it will tend to be rapidly not available to any user. Whatever term you use, think about what your users are, aside from âusers of your system.â
- Throughout the design and execution process, you need to check back periodically, to make sure you are still on track.Like I just said, you check against project goals and design principles at each milestone, or every time you make a major revision (or scope change) to make sure it still abides by these objectives.
- Actually, there are two different issues here. Not just that the design, as executed, is still good, but that itâs the right thing to make. Heuristics can tell you, generally, if itâs a good solution. A generally usable solution. But you must refer to the project (or program) goals and the design objectives and principles in order to tell if you are making the RIGHT thing. This is not a trivial problem.
- Sometimes, often in fact, the evolution of the project means that you discover a principle is a bit off. Or not clearly stated. Or something key is missing.Thatâs fine. But it doesnât mean you slowly discard the goals and objectives and go with gut feelings, or âwhatever Apple would do.â You have to, very deliberately, with everyone on the team involved, change the principles. Write it down, and stick a new copy on the team share drive, and tape it to the wall for everyone to see. Projects, and products, evolve. But they cannot be allowed to DEvolve, and degrade into navel-gazing nitpicking.
- Implementation is a key part of this whole process, and not just because it is how the product gets to the end users. I mean here, including implementation considerations and implementation team members in the design and evaluation steps.Note that I hesitate to say "development." It's best to raise that up a level, and discuss how the product will be built, hosted, released and maintained in the same breath as how it is designed, marketed, sold and paid for.This might seem like the same argument I have been making about designing the whole product, then designing individual parts. Because it is.
- So, how do you implement this for multiple platforms if not "responsively"? Well, "correctly." Remember how I said that /usually/ you want to build and launch for the mobile web first? Well⊠sorta. Thatâs a convenient talking point, since itâs the first thing that can be called a product, that customers can see and touch. And, the people who pay your salary can see it also. But really, you start by implementing the services. The datastores, backend software, business rules and methods to access these.
- âŠfor every platform. If you have even a glimmer in your eye (much less actual plans as Iâve been discussing) that this product will expand to other platforms, you cannot bake the software into the first platform, or build one-off calls to the datastore. You have to build for the future, so each platform can use it.Even platforms you havenât considered. And, if you do this remotely correctly, you donât need to predict what platforms will use it.
- Layered development can be hugely efficient here, so pull as much software off the presentation layer as possible. For two reasons.
- Efficiency. Sure, code efficiency. If we donât have to touch every bit of code with every release, thatâs great. Hardware and configuration efficiency also. There should be one datastore, not synching if we can avoid it, and one service call that everyone shares. Build it once.But also, data transfer efficiency. Put as much processing on the back end. Put intelligence next to the data sources, or at least on cheap, high-speed pipes instead of sending them over the radio. You just send to the device what is needed. Remind anyone of some principles I talked about earlier? (This is also cheaper in data costs, and more secure. Lots of good reasons to do this).
- Then you can build the presentation of individual platform codebases that take advantage of not just the UI and interaction differences, but the common service and data framework, and the available tools and processes of the client platform. Whenever possible, inherit features, or use default functions. Iâve seen ugly but running complex products built in a day. But it took weeks of software development before this. Individual platforms you say? How many of you launch, at more or less the same time, your product on several platforms? You do the web, iOS, Android, Blackberry even⊠So, doesnât juggling all this get all out of hand in a big hurry?
- Well, if you donât plan well. For years now Iâve been saying that my design deliverables are themselves designed (I even did a project once where we were able to do usability research on the design documentation). Since then, Iâve started believing the design process has to be designed also. And now, I push for the development process to be designed as well.And just like heuristics and best practices donât always meet the needs of the product design, neither does any one development process.
- The one Iâve been pushing for a while, is the Staggered approach. Apparently this is shockingly unique, as I keep finding development managers who have never seen anything like it. Resources, software design, business oversight, and UX work hand in hand, both from process and resource availability points of view. You generally still engage a team per platform (though sometimes you can recycle part or all of a team if thatâs your way), but staggered starts mean there are efficiencies, as every subsequent team can learn from the mistakes already made, and re-use work already done. Note that the first platform is indeed âShared Services.â The highest priority platforms go first, and the risk of them finding errors is entirely counter-balanced by the much, much longer QA time. User research and longer acceptance testing can also be implemented in the first platform or two, and the general learnings applied to the others. Overall, later platforms should be much easier to implement on, even if they are 100% new presentational codebases, as the software, architecture, algorithms, content, and much other work is entirely done.
- The exact timings, the platform mix, the method of testing⊠all that is unique to your organization, the platforms you are pushing out, and your product.Iâve worked on products where we had such long phases of service development, that we had to bake in PUI (Programmer UI). A fake presentation layer so everyone could see that it was working, check the service calls over network connections, and so on. That was a throwaway phase, but counted in many ways on the planning diagrams as a platform. The test platform got itâs own swimlane. But thatâs not typical. Your mileage will vary.
- Actually, donât do anything I have done. Well, not exactly. But the principles are goodâŠ
- Design makes choices based on good principles, develops or uses patterns based on user needs and business goals, and builds solutions based on schedules and business or technology limits.
- Your processes should, likewise, correspond to your organizational culture â or that of your clients â your needs as a project team, the âtechnical limitsâ of how itâs integrated into the rest of the organization. Design and implementation processes, should always be improving. Not just following trends, but picking up the nugget of a good idea, and applying that when it works for your organization, your process and your project.
- So, since I keep saying âprinciplesâ hereâs the best I can do to narrow them down to pocket-sized:Be RESPONSIVE â> Actually multi-platform. And from the server level, not just the presentation layer. Be NATIVE - > Use device capabilities, way past reacting to size. Build for PHYSICAL use - > Design to the userâs scale, using real world sizes and real-world interactions. Design BUILDABLE products - > Implement the way you design, and design in ways that can be implemented. Execute in EXENSIBLE ways - > The core of your product is probably data, so design and build generalized, reusable components and services.
- I hope there are questions. Ideally, very detailed or technical ones.