This is Swipe, a blog by pinch/zoom about mobile, design, user experience, usability, development and the future of technology.
If you’re a mobile designer looking for inspiration, check out Lovely UI, a collection of mobile UI screenshots. Elements are tagged nicely into dashboards, nav and sub-nav, buttons, textures, lists, sliders, and so on.
From the looks of it the site is still relatively new (about a month or so old) – it’s a side project by Diana Frurip. This looks like it’s going to grow into a great resource with time.
I’ve been impressed with the Windows Phone experience, since the day it arrived. I often say, in a post-iPhone world, this is the first platform to really invent something new. In fact I would gladly carry a Windows Phone instead of an iPhone 4 if the hardware wasn’t so clunky—anyone that knows me that is saying A LOT.
I’ve been very negative towards Microsoft mobile strategy for years, and they seem to be turning it around, from devices to their browser strategy (a better browser is coming!). The proof was when we talked to Joe Healy at CTIA. He gaves us a rare (and excellent) walkthrough of the design considerations that went creating the Windows Phone 7 Experience called Metro.
After seeing it, I’m an even bigger fan of the mobile design team over at Microsoft for making the hard choices and creating something truly inspired.
Our friends at Web Directions have posted a great report on the State of Mobile Web Development what tools are people using, what is the most interest to them, etc. They interviewed 1,300 professional web developers to gain insight into the day and the life of a web developer in mobile (I’m curious how many would consider themselves “mobile developers”)
Some of the key findings:
Web Directions Unplugged is next week here in Seattle. We’ll be there and if you are reading this, you should be to. Use the code ‘pinchzoom’ to get 30% off the ticket price.
This may seem like pretty nerdy-news, but Couchbase announced the first release of Mobile Couchbase this week, which we are pretty excited about.
What does this mean and why is it important? Among developers and data guys there is a general movement referred to as NoSQL or a move away from slow relational databases to simple flat structures that scale horizontally.
The principle is that your data will evolve in ways you cannot predict and needs to be accessible from a wide assortment of contexts and devices. We see this problem every day in mobile—step one of any mobile design is data modeling. This is often the most important—and often immovable—constraint to creating a mobile experience for any platform.
The problem is accurately summed up on the Mobile Couchbase page:
Users are turned off by slow applications, even when the slowness is due to network issues, not your code. With Couchbase Mobile, your application is always snappy, and never has to wait on wireless carriers or remote servers. Your users will thank you.
Couchbase is lightweight and saves battery life compared to traditional applications. By synchronizing data to the device, we optimize bandwidth usage and avoid expensive radio transmissions during everyday usage.
Count us in. We’ll try and play around with this next sprint and see if it delivers and report back.
When I was researching my book, I polled a lot of my peers in the mobile community on how they handled the different capabilities of different devices. I compiled it and created a device matrix to help developers easily identify which class of device to support based on the Yahoo! style of browser grading (jQuery Mobile adopted a similar matrix to show which browsers their framework uses).
Using this matrix Class A devices are the most feature rich and capable, Class B less so, and so on. While I think my Device Matrix stands as a way to classify all mobile devices on the global market, in today’s arena of smartphone-focused design and development, further definition is needed.
The problem is most smartphones today ship with a Class A browser, but what you can do with it differs greatly. For example while the iPhone, Android and BlackBerry all have WebKit browsers in them, they do not support or interpret standards the same way, as PPK described on his blog. This makes for time consuming debugging and costly overruns.
The best approach is to call out the specific user experience goals you hope to achieve up front and focus on the devices that support it. The problem is the desired ubiquitous user experience is often less achievable than one imagines.
At pinch/zoom we created a new matrix that we’ve been using internally to help people understand the different classes of mobile web app. In this article I’ll share the Classes of Mobile Web Apps that we use to help clients understand the advantages and disadvantages of the medium. In a future article we’ll dive into some of the specifics and share some of our internal testing methods.
A mobile web app is an application built with web technologies that is accessible via a mobile browser (either the standard device browser or an embedded browser known as a “Hybrid app”) and not exclusively through an app store or marketplace.
Typically mobile web apps are designed to emulate a native application, sharing the same basic layout, controls and screen to screen interactions. While there are many exceptions, the vast majority of mobile web apps and web app frameworks closely follow the iOS aesthetic and interaction model.
However a mobile web app will always be limited to the capabilities of the browser available. This environment cannot be assured at the time of development and therefore we use the below classes of development and support to help us prioritize design and development effort.
A Class 1 Mobile Web App uses the latest innovations and capabilities present only in the iPhone (3GS and higher, iPod touch 4th Gen, iPad).
(1) This is the big misconception around mobile web apps. There are mobile web apps and there are iPhone Web Apps. While the same basic support may exist in other browsers, using the same code on different devices would create a poor experience for the user. Just because you use web technologies does not ensure cross platform compatibility.
A Class 2 Mobile Web App supports high end WebKit browsers with devices that have at least 1Ghz processors (all iOS devices and most 2010 model Androids).
(2) In this class we technically could get close to a Class 1 experience on many devices, but it is not advisable. It is very difficult to maintain a consistently good user experience. The noticeable limitation is the lack of hardware accelerated CSS transforms to perform animations and interactions. Javascript-based animation needs to be used instead, or animations need to be omitted altogether.
A Class 3 Mobile Web App has the highest degree of smartphone device compatibility, provides for high quality user experience, as well as supporting higher and lower classes (supports all iOS devices, all Android devices, BlackBerry Torch).
(3) This is the Class I typically recommend to clients based on a “future forward” look at the US smartphone marketshare. However they are often mistaken in believing you can have a Class 1 experience but support a plethora of Class 3 devices.
A Class 4 Mobile App is designed with compatibility in mind, seeking to have the best possible user experience across the widest number of devices. This is the best approach for supporting Windows phones or BlackBerry devices other than the Torch.
(4) Any mobile web app looking to have the maximum cross platform support, should look no further than a Class 4 experience, which is more website than web app.
A Universal App (sometimes referred to as Responsive Web Design) is an experience that is built for multiple device contexts, but with a single source of content. Under very specific circumstances the user experience of this approach can be equal to a Class 1 Mobile App.
(5) While this is popular with most developers looking for a “write once-deploy everywhere” approach, the user experience is driven by technological constraints, not user needs. The LCD approach is something that has proven unsuccessful with most mobile platforms and applications for over seven years.
Hopefully this helps. And if you have any tips, tricks, questions or comments, please post them over at Hacker News
With every project we attempt to find the balance between creation for our clients and innovation of the mobile medium. This means we are always inventing a lot of new stuff to address the problems of mobile for our clients that we can’t always share.
For the last year we’ve been purposefully quiet as we worked on some pretty big projects for HSBC, NYT, ADP, BBC and others. We are trying to break out of that habit in order to share some of the lessons we are learning without revealing any of the secrets we are entrusted with.
It’s not easy, but I’ll give it a shot by doing a public Sprint Review of some of the lessons we learned these past two weeks, which we refer to as Sprint 8.
We’ve switched the entire agency over to agile a few sprints back (we do two week sprints). Meaning from Mobile Strategy to Design to Development, we are fully agile.
This of course works beautifully for development but for strategy and design we’ve had challenges. A lot of creative work still needs to take a waterfall like model to reflect institutional buy-in processes. The biggest problem is we can complete the work faster than clients can approve it. This is something we are still working to resolve.
In this sprint we learned that agile for agencies does indeed work, but we have to really push clients to approve things faster otherwise they need to fund the delays (which is never popular). We also learned we need to spend more time educating clients on the benefits of agile in mobile.
I have always believed in straightforward billing. It should be easy to communicate and easy to calculate. You will commonly hear me say: you can’t argue with math. We’ve been mostly billing per project in the past, which works for design but not for development. Over the first two years we learned it is impossible to know how much time it will take to create good app until you start doing. Therefore it is impossible to accurately estimate a mobile project at the start.
With adopting agile, we’ve moved to a simple fixed price per-person/per-sprint pricing model—basically like a mini-retainer. This allows us to appropriately resource projects while still remaining agile.
Exit Criteria is basically the tangible objective(s) of the Sprint that is defined at the beginning during Sprint Planning. It should be able to be evaluated at the end of the Sprint in some sort of artifact that proves, yes we did, or no we didn’t. It focuses the team on things that they can complete and be proud of as well as something the client can review and cycle internally for feedback. The net benefit is it has allowed us to spend less time worrying about time and budget and more time on the details the client isn’t asking for—something we know is a huge difference in the mobile market.
Exit criteria is not only great for the team, but clients are digging it to. We communicate our internal exit criteria verbatim to clients at the beginning of the sprint so they know what to expect.
However writing good exit criteria isn’t exactly easy and takes practice. Try writing a statement that positively will or will not be true two weeks from now. For example: It will be raining two weekends from now (okay well for Seattle maybe that’s a bad example).
Here is a simple one we use on most projects: Test devices are provisioned on Test Flight. At the end of the sprint we can either prove this happened or we can’t.
In fact good exit criteria can be summarized by something our Product Manager Bryan Zug keeps saying:
Show don’t Tell
Another benefit of shifting to all agile has been the ability to prototype sooner. We’ve always known that getting an actual prototype or proof of concept in front of clients has been valuable. In the waterfall method, you schedule the prototype as a deliverable, like a mid point between two phases. In agile you use the prototype as a tool to learn something you didn’t know before.
From the clients perspective maybe there isn’t a noticeable difference, but from the perspective of the team that has to design and build an app, this is huge. It increases quality while simultaneous reduce risk of cost and time inflation.
You are probably thinking: shouldn’t this be #1? Maybe. From our perspective we learned last summer that when it comes to mobile, the web promises more than it delivers. Since we don’t like to make any promises to clients that we can’t prove, we try and accomplish a task using only web technologies with every project. We typically fail, learn that the web is broken in some way, eat the cost and then do it natively. Then we try something else with the next project (I believe this is the definition of insanity).
In this sprint we learned that the way viewports are currently designed they constrain the design and interaction of your content to the vertical axis (e.g. scroll). While we can accomplish a layout on a horizontal axis (e.g. swipe) for small niche projects, it requires a heavy amount of manual coding that for large projects is completely unsustainable.
In this sprint we produced a bunch of content on this topic:
Next sprint we are to kick off a HUGE project that will test the limits of the web, responsive/adaptive design and layout and some of our assumptions about the state of the web.
This sprint we found quite a few different ways that today’s CMS landscape is holding clients behind on publishing to the mobile domain (web or native). On two different client projects we had to design and invent technology to circumnavigate the limitations of the two different (and popular) CMSs. This was in addition to a few off hours experiments I did with creating a mobile-friendly CMS.
We also learned that interlinking web content within a native container is completely broken and most CMSs don’t know how to deal with multiple hyperlinking methods. Again technology has to be built to resolve this problem, which is further fragmenting the core technology we use on the Web.
The good news is that our own Project Canada which seeks to resolve this problem reached a big milestone. We are one big step closer to releasing it.
This sprint I wrote about the risks of being a technologist and overcoming ego to help people with real problems. Not only did I personally suffer from “being in the weeds,” but I saw it around the office too. Many struggled to communicate the many challenges of mobile to our clients in terms which could be fully understood and communicated to others within the client organization. The challenge seem to stem that we have more to communicate than we have time to educate.
This sprint we had a bunch of activities around sharing some of these common challenges in more accessible language. Creating a bit of a mobile curriculum (I call it a boot camp but the name isn’t sticking with anyone else). We don’t have anything that is publicly available yet, but the goal is to have it soon.
{whew}
Holy crap, when I write all this out it seems like a lot, especially given we were two resources down for half the sprint. But honestly this was just a “sprint” in the life at pinch/zoom.
If you have comments, tips or tricks to share for us, please post on Hacker News
In this segment we talk about iPhone becoming the top camera on Flickr, AT&T record quarter of smartphones, Verizon and ask the question, if Android is the top selling platform in the US, where is the proof?
See the entire episode on Vimeo: http://vimeo.com/22900281
In this segment we talk about how mobile is changing the way we read and shift content around our different devices. What is the role that apps like Instapaper and Readability will play in the future and how does that change the way we look at the data we call content?
See the entire episode on Vimeo: http://vimeo.com/22900281
I saw this link to a random discussion board yesterday. In it David Mark has written one of the better criticisms of mobile web apps I’ve seen. He starts by calling out the problem:
It seems “applications” that sit atop (usually invalid) Web documents are dead. Even the best JS programmers can’t compete with the worst (proprietary) app developers. It’s not even close to a level playing field.
He is absolutely correct. The time it takes to create one decent mobile web app for only the iPhone can be equal to the time it takes to create that same app natively. Add one additional platform like Android to the mix and your project blows up.
The numbers just don’t add up. (I talked about the costs of native vs web in my Breaking Development presentation)
At pinch/zoom we keep trying to push the limits of what web tech can do and we keep running into walls with no solution in sight. The roadmap for web technologies just isn’t there… yet. That in itself doesn’t scare me as the web is amazing at adapting. What scares me is no one seems to realize just how far behind the web is.
The web of today is like a dyslexic child failing at school. The parents keep refusing to believe that anything could be wrong with their child and blame the teachers instead. You simply cannot address the problem until you realize a problem exists. When it comes to the web no one wants to admit that the web has a terminal disease.
I see Web developers trying desperately to make their documents look/work like native applications. At best, it’s a waste of time. At worst, it’s destructive as overzealous developers step all over browsers’ inherent capabilities and replace them with flaky scripts that ostensibly give them more “control”.
I completely agree. The overhead to learn and use these technologies is a pretty big investment with no guarantee that you will be able to deliver a shippable product at the end of it. At least with native code you know you’ll have something that works. You have control of the conditions. Once you add the web to any app, you begin to lose that control and the viability of the product, schedule and budget.
BUT
I don’t believe we should ever stop trying to push the web further. The web is and always has been the only ubiquitous mobile platform. That has value and should be pursued. But alas investment coin is not going toward building ubiquity it is going to other walled platforms that claim openness. That needs to stop.
every new wave brings with it attention-craving bloggers who will say anything to get aggregated. I see they are out in force with regard to “mobile web sites”.
I love this last point. Mobile is an entirely different medium. It follows different rules than the web as we know it. There are many that don’t get mobile, but like to judge it anyway. They believe that mobile should follow the same principles as the web and will evolve in a same way that the web did ten years ago.
That is pure fantasy.
Assuming that mobile will follow anything that happened with the web is to imply that mobile is ten years behind the web. With a little research one can find that mobile is far more advanced and sophisticated than the web—and it has been for many years.
If anything, mobile of today is 5-10 years ahead of the web.
So in the spirit of my post yesterday what can we do to make the web better? What can we do to help spread the word of the shortcomings of the web and structure the road map for tomorrow?
I for one have a renewed belief that the web can be a viable mobile platform after attending Breaking Development I am looking forward to renewing the conversation at Unplugged in Seattle next month.
See me there, or follow me on Twitter and tell me what you think.
A friend of mine convinced me to go to the Seattle Social Media Club last night. Normally I look down my nose at anyone that uses the words “social media,” but the topic of the evening was mobile, so I figured this is probably something I should sit in on.
The event was completely misguided. It focused almost exclusively on how to put “social media” on mobile—by that I mean how to use mobile devices as an advertising channel. The speakers, moderator and attendees seem to completely miss the point of mobile. I sat there getting more and more pissed off, not at the people, but because they didn’t have the right information. Worst of all I didn’t know how to get the right information to them except post some latently snarky remarks via Twitter.
Near the end of the event I started to wonder, what if I am the problem? What if I am too stuck in the weeds of mobile that I have lost the ability to hear what real business people have to say?
Let me come back to that.