Working Together for Mobile 2.0 (or 4.0)

Brian Fling's Mobile 2.0 thing is not quite a manifesto yet, and as he points out a lot in the document, has not even gotten the community traction that it needs, but is still something I mostly agree with. And, want to help with. I think things are mostly trending better. Worse a few places, but mostly better. I am thrilled with new things like Mozilla's Open Web App Ecosystem, so much so I talked about how much we needed one a week before it was shown off. Now, I'm gonna talk specifically to some of the points Brian makes in his document. And try to help with a couple of them.

A Mobile Web Coalition/Task Force: All my attempts to create a Mobile Web Coalition has failed since sending this email out. The problem is that no one has the time to invest in attacking such a hard problem. I’ve attempted to get corporate sponsors, but everything is just keen to do their own thing.

I have always agreed, and now that I'm applying for jobs, and am reviewing and trying to share what I made, I am annoyed how many are NDA restricted. It reminds me of Kim Lenox's post lamenting the good design of the iPhone because we all had many of these ideas already. And even aside from secret clients, I've worked for companies where you couldn't discuss anything. I once got smacked down for discussing on a UX forum information about the team that had been published in Business Week. This is all the antithesis of scientific exploration; we can't get far, much less consistent, without sharing, and collaborating. What am I doing to help? For several years now, I've been gathering up my mobile design elements (and other stuff, like touch guidelines, and type info) as a document, and sharing it with everyone as Mobile Design Elements. It includes a lot of components from deadly-secret projects, just pulled out of context and categorized so you can't figure out secret things. You can go get it from a page on my wiki there, where I share it alongside everyone else's stencils and templates. Use it as you see fit, share again, modify, etc.

Mobile Web Resource Site: Since the book came out last year it has sold pretty well, but I’ve still made no money from it, and all mobile inquiries that O’Reilly gets have been going to other authors. Looking back I would have been better off making all the text of the book free and public... but that is another story.

I agree we need one. I've been adding to a wiki of mobile resources for years under the Little Springs auspices. But no one else much did. And that is probably dead now anyway. What am I doing to help? I am one of those guys that O'Reilly is sending inquiries to. And (with Eric Berkman and some of our former interns) have been working on it pretty seriously for a month or so. It's just a patterns book, and it's general mobile, not just web, but I am trying to make it useful and well-researched. And most of all, part of our agreement with O'Reilly includes letting us put all the content on a wiki. So, I started a new one, and have added the whole outline, a dozen patterns (more every day) and a bunch of other resources: http://www.4ourth.com/wiki Please help. Or, don't contribute, but do feel free to use it so we at least all have the same language we work off. Since I am trying to write a book, and there's a deadline, try to be respectful of the info, and accept when we are jerks and cut off discussion in order to lock at least a version of a pattern, so we can move on. But do please help. I want this to be a community effort, so want to hear from you guys even if I disagree. And if you wondered about the name, it's mostly short and cool, but also because I think "2.0" is over used as hell. And if I think about it, I think we're in mobile 4.0. Explained slightly more at the home page for the whole site if you really care.

Mobile web zengarden:

I think even the desktop web is still missing the permanency and credibility of print design by having no big awards shows, or exhibit spaces. Mobile is far worse, due to the even speedier and broader variability of the devices. I am not sure the CSS ZenGarden approach is the way to go for this (and I'd like to see one less web-specific) but something is needed to let everyone see, to get good ideas (and preferably with implementation tricks shared also) and maybe a way to judge or rate for suitability, somehow.

Mobile 2.0 CSS Framework:

I know way too little about this one, so will leave it to others. I do worry a little about a major facet being so focused on the web. And not because I like apps. I like... everything. What about principles OS developers can follow? What about tools to encourage development of services, like SMS and location? Oh, and what about js libraries? And other plugin technologies, even for web alone?

I quoted Umair Haque in the final chapter of my book in his call for the Next Industrial Revolution and I’ll quote him again here...

There are days I almost hoping for someone to plot from their secret volcano base and take over the industry – even with something sorta crappy or restrictive – just so there's a single experience. Not just a single browser, but so interop becomes not an issue, and I can get location from the handset to the web, and... so forth. Way, way, way, too much stuff is locked out or restricted because of perceived quarterly returns, and I think everyone would be better off working together on standards. Clearly, none of us are CEOs and going to be able to go out on a limb (at least one strong enough the board won't fire us) and make this happen at any one company, much less across a whole chunk of the industry. So we need to start working, together, towards the goals Brian laid out. To work together, to gather ideas, to share them, to have goals as a community. And to talk about all these as a single community, so we speak the same language and start working together, instead of against each other.

ALREADY Seeing Significant Mobile Traffic

“ It used to be that us mobile folks like myself had to convince someone with a website to build a mobile version in the hope that they could then tempt some traffic their way. However, it’s a much easier discussion to have when the publisher is ALREADY seeing significant mobile traffic, and they just need to make the decision about how to serve it better. ”

The increasingly quotable Mike Rowehl in Thank You Twitter and Facebook, about how we've finally passed some tipping points in corporate mindshare; the chicken & egg proposition is over, and seeing traffic come from mobile (via, especially, twitter and facebook) makes them want to optimize mobile sites and build mobile apps.

Influencing the Requirements Process - Designing Documentation, Part 2

Specifications are hard. There are a lot of conflicting needs, and the complexity of the documents might be more severe than the product you are specifying. Aside from designing products or interactions or interfaces, I spend a lot of time designing the documents themselves. A happy ending to this sort of process is detailed in last week's post on Designing Requirements Documentation.

Which might bring up the question: What type of specification? Design documentation, which is most of what we do (well, by hours – most actual documents by count are proposals and emails and so forth) took a long time to settle on, but it has evolved into something pretty specific and which works very well to communicate to everyone on the entire project team. There have been several evolutions, many mandated by technology alone; I used to do everything as a single sheet which functioned as sitemap and flowchart and detailed page/state layout. But when I had to work with more remote teams getting 36" x 10' pieces of paper to them was more difficult and had to change to something else.

But complete technical specifications are still something else. There are also content specifications, style guides, and lots of other documents. But today let's talk about the general technical specification, that developers use to build or modify software or presentational code to meet your design needs. Integration of technical specs with design has always been an issue. I've spent a lot of time messing with my deliverables to make them comply, or revising them to be pasted into the appendix of an IT specification. All of which is fairly unsatisfying and never helps much.

It is also important to believe that design documentation is good, important, valid work. We spend a lot of time buried in IT process, and I have to fight even people here at Little Springs to make them believe that our work and our method of work is valid. Sure, you can use IT requirements documents to do your work, but that's not their intent, and there are better ways to do it.

After a lot of work imposing myself and my team into the development process with our own documentation, way back around 2002 – while working at Sprint, I got to work my design documentation directly into the technical specification. At the time, Sprint IT used something called Application Design Documents, and I was able to persuade them that the UX team could do the best, most efficient job of making some of the document.

Note that the text and tables are in the IT format, specifying the behavior of each widget in a specific manner. And the screenshots (I prefer other methods, but this is what they could handle at the time) are placed in a process-compliant manner, but there are just about 20 times as many as usual. I also did a lot of the writing, or at least editing, of the specifications, so when it was done both the IT analyst and the whole UX team agreed on the behavior of each and every feature.

This product, both by design and implementation, was a high-water mark in ease of use in my career. Web-initiated SMS with millions of uses a day, without a help system and hardly any error messages, with impossible uptimes and no measurable customer complaints. Almost unheard of for a mobile telecom operator, at least in the US. And although it took forever to create the document, some of this was simply getting everyone involved used to the new process, and we saved a lot of time correcting errors and explaining stuff in development.

But then that dream died. After a few months of work, a big fire-everyone-for-IT-outsourcing binge left disappointingly few software designers and analysts in house. I had to start all my relationships over and reconsider how all deliverables would work with random, far-away teams using them. So for the next few years I made do by improving my design documents, communicating with project teams as much as possible, and actually writing requirement documents when I could.

Writing requirements

Which became a key task I tried to accomplish. If the UX team got engaged early enough (which is always a problem) I pushed to review and approve the requirements. Then I found out no one wants to write them, so simply volunteering gave the UX team lots of additional authority.

A key reason I like working on requirements is that they are often poorly done. For example, Business Requirements and Functional Requirements are too often conflated. A BR document is very, very high level. It contains the goals of the project, and rarely more than a couple dozen, or that's a sign you either wrote them wrong or the project is too big to be completed. Some Business Requirements you might read are:

• System shall have the ability to allow user to enter a street address and geocode it to a dynamic map displaying coverage and signal strength.
• System shall have the ability to drill down from a national map perspective if no address on file for user (i.e. in-front of log-in).
• System shall have the ability to allow user to enter only a ZIP code and geocode it to a displayed map.
• System shall have the ability to allow user to enter an intersection and geocode it to a displayed map.
• System shall have the ability to allow user to enter a City/State combination and geocode it to a displayed map.
• Etc.

But this is dead wrong. System? And so very many. That's a set of Functional Requirements, and not a well-written set at that. But all is not lost. Assuming that the marketing and product people like these, you can redo them as actual requirements. A typical, well-written Business Requirement could read:

• Allow customers to find coverage for a specific area in multiple ways: by entering a general location, a specific street address, an intersection, two locations, etc.

And this covers all those bad requirements above, and then some. Cases you don't think of at the beginning of the project are still in scope. A half dozen more like this and you have a project.

Functional requirements

A Functional Requirement on the other hand provides specifics of technical, logical, or presentational behavior. These are also boring, so often don't get enough attention. Oh, they have to be written to proceed through the IT process, but no one wants to do it, so they get poorly written. If you want to make sure the product gets built right, and that the implementation teams are doing what you designed, just insert yourself in the process.

Good Functional Requirements look like this:

FR-40 From within the Wired Web unified messaging access portal, a function will be provided for customers to move SMS messages between folders, (e.g., Inbox, Outbox, Spam).

Better written Functional Requirements help a lot. Some notes about requirement writing were in the earlier blog entry, so I won't repeat them here. But they better not all start "System shall" or "Ability to." Even if it's nerdy, academic, and technical, with otherwise annoying neutral-voice characteristics, use good english, first and foremost. The above requirement is written the way I like them all to be. First, the condition or state From within. Then, who can do it, here the customer, but the system may automatically do things at certain times or when certain conditions occur. And then, what happens. Pretty generally. An example of the folders are given, but there's not a requirement for each folder, and a comprehensive list is not given.

Not just because this would be cumbersome, but because it would be wrong. Remember, there are other documents and other requirements. The structure of the folders here is likely described in some architectural specification. So as part of this writing, be sure to understand the scope of the document, and how it works with the many other documents that are part of the IT process upon which you have imposed yourself.

The product is more important than you are

And after all that, it is a bit thankless. Your name will probably not be on the document as an author, and everyone will credit the analyst, who may not credit you. That's fine. Often, it's preferable, since UX is viewed with dark suspicion by parts of the organization.

Even as a vendor, we pretty often deliver work in someone else's template (or, have to create one that looks like the client's brand).

Getting the product right is most important; work on how your team is perceived later. Which is probably a good topic for another post in the future.

While I won't be hosting a process workshop at this year's Design for Mobile conference, there's plenty more to learn about mobile design, technology, strategy, research and implementation. Still some space available, so join us in Chicago next month.

Why should I be the expert?

Tax prep software, I am told by folks who build it, is an expert system. It knows all about it's domain area, and solves problems for me based on this knowledge, and likely information and outcomes. So why am I the expert? I regularly have no idea, at all, what it's asking me but the assumption seems to be that I understand the jargon perfectly. As 2008 tax paperwork begins trickling in, I start thinking of the great idea I came up with last year. How about I don't fill out forms the way the government, or any tax-expert does, and instead I just gather my documents, and enter those. So, right now, I can go to the TaxCut site and say I got a form. They guide me through obvious choices, and I pick "its from a bank or investment management company" (of course, they offer last year's forms and companies as an option) and tell me it's probably a 1099-INT, then I enter that info. Weeks later, as it determines I have probably got everything entered, it asks to make sure, and then goes through all the questions about if I have any farm income, or am blind, or dead or whatever. But why not look at the actual use case, of everyday folks, frustrated by taxes and the piles of paperwork, and use that to solve problems instead of creating more.

Why I hate Google Chrome

Simple, really. Because it's already ruined a perfectly good word used for describing bits of a browser. I am specifying [something about a browser] and have used it to good effect several times in the last two days. Chrome is the stuff around the edge of the viewable area. The toolbars, scrollbars, status bars, and so on. But I am pretty sure it's already starting to confuse others, and people regularly email or IM me about "chrome" and I have to contextually figure out they mean "google chrome web browser." I have much the same argument with many of Apple's apps. Mail, for example is resolutely un-googleable. A convention has popped up to call it mail.app (which it sort of is, though the dot app bit is hidden usually), so you can actually tell when a discussion of it is happening, versus the USPS or email in general. But I am probably just an old curmudgeon.

Clicking behavior in web browsers

I got challenged earlier today to back up our assertations that history menus in web browsers are poorly used. So, off to the internet to do research. Or, rather, find other's research. Found a really neat paper that solved all our problems. A 2007 study (and there are no others for years before) that looks at lots and lots of user click data, and reviews the whole state of the browser today vs. what it's being forced to be. Worth it if you design interactive systems at all, and especially for any of the webs. If you have an ACM account, you can download the paper from here: http://portal.acm.org/citation.cfm?id=1240624.1240719 Or, there's a slideshare of it in summary.

Web Page Revisitation Revisited

View SlideShare presentation (tags: chi07 chi chi2007 web)

Seriously? That's your excuse?

So, if you use Netflix at all, you might have heard about this insane plan to eliminate profiles. They were neat, a way to organize lists, like one for movies, one for series. Or one for each family member. I needed it because Netflix also has a limit of 500 disks per queue, and I am over that limit. So, the other day they announced that these would be eliminated. Completely. With no migration. They just disappear in two months. Check out this particular reason, though. Yeah, all the usual, but also:

...keeping our service as simple and as easy to use as possible. Too many members found the feature difficult to understand and cumbersome, having to consistently log in and out of the website. Continuing to maintain the profiles feature for the passionate few who use it (including myself) distracts us from the mission of presenting to all our members the easiest way to find the best titles for them...

Okay, the system was somewhat cumbersome. They assumed each was a person, so you had to have a different email (username) and password, and it did some other odd stuff like the first profile is the account owner, so when signed onto another you cannot get to account details stuff. But they are claiming that this poor design means that the whole function is worthless. What? This is a terrible way to use design to justify product features. How about a redesign? How about labeling and marketing it correctly, so more than 2% of users can find it. BTW, I think that's a pretty good use rate for such a poorly-communicated service. To clarify, I am not totally talking out of my ass here. I have designed a few profile-based account management systems, mostly for much, much larger organizations than Netflix. It's not that hard, and it's extremely a better idea to fix than discard. Oh, and the users who employ such systems in detail are the good customers. For an MRC based industry, it's always true that churn is expensive; why annoy these folks. I for one have been a pleased (evangelistic) customer for over 7 years, yet I am willing to consider other options now. Okay, I did participate in turning off a system once. At Sprint we were required once to give the ability to customize the account management screen. People could close portlets and move them around. I had poor hopes, but we worked as hard as possible to make it easy. And it tested okay, so no design issues to speak of. And... it was used at appallingly low rates. One year post launch, while working the next release, we checked and found about 5,000 people had ever customized it. We had 7-8 million customers at the time, and maybe 3 million regular users of the web account management system. That's (appx) 0.0016%. This we tossed without regret. 2%? We'd have kept it for that use rate.

I never get threatened over the internet!

I am so proud. Got this just this morning:

1. comments = Steven: I have requested twice, via this e-mail section of your website that you remove the old version of the Alphapointe website that you currently have posted at the following address: http://www.donttouchme.com/web/sites/alphapointe/products/products0.html Alison called me and I explained to her that we have a new corporate website, and I think that having this website available is potentially confusing to our customers. If you wish to use our company website as part of your online resume, then you are free to do so in the form of "screenshots" as long as it is clearly marked as such, and is not part of a working website. Please note that you are not authorized to use our company name online without consent from Alphapointe management. As such, we ask that you comply immediately with the above request. Failure to do so will result in legal action. If you wish to discuss this, I can be reached at (816) [redacted]. Ragards, [redacted] Chief information Officer

This is about my interactive design sample page. I post all sorts of source code for designs I did, as well as live site links for some. Sure, I took it down, partly because I don't care. It's old as hell, and not that good a design. I am not sure what a "screenshot" is, but I am not switching any of these to screenshots, cause that is lame as hell; I generally disregard samples from resumes submitted to me that are only screenshots. For web design, I want to see how it works in a real browser, and how it was coded. But seriously. I legitimately worked on it. We had no NDA that covered "don't tell anyone you worked on this" and it was like 12 years ago anyway. And how would /anyone/ get confused and think this was their website? I hope no one is confused by the old version of their website on the wayback machine. Someday I hope to have the money to hire lawyers so I can go ahead and ignore things like this. Oh, and the first email I got I ... never got. Email, not a good way to give legal threats. Number 2 I got while living out of a tent in the woods for a week. No real chance to do anything about it then (cannot ftp in from any old place, especially over very high latency cellmodems).

Why does Opera Mini hate me so much?

That's what it feels like. I have been through... I forget, but 3 or 4 versions of Opera Mini on this phone. And a couple on my previous one. I forgive them for changing the featureset. So the manner in which bookmarks are displayed changes. And I got it when there are pre-populated bookmarks; that (and browser/homepage search) is where the money to pay for this comes from. But I do not like how every time I upgrade the software ignores everything that has gone before, especially bookmarks. This time I am particularly aggravated by this lack of upgrade path. Now that its out of beta, the beta browser yells at me all the time that I should upgrade. By manually typing, in a totally different browser. Actually, at least on mine, a link to a download would work out. And how hard can it be to go check out the config files from the previous install? So, after the always annoying install process for mobile software, I still have to rekey all my bookmarks, then uninstall the old version.

What happened to the dream of hypermedia?

Cast your mind back, to the days before the internet even, when anything was possible. Hypermedia (by whatever name) was going to link all information to all other information. Don't understand a phrase? Just click and look it up. A reference to a scene in a movie? Just click and see the clip. But with all the interactive sites, and widgets and plugins and flash players and everything, I have had this experience maybe half a dozen times. A way to get close is the best Wikipedia has to offer. Clicking about their universe can be very enlightening in these cases. Its often much worse than this, with broken links, or a page with hardly any links at all, or stoppages due to digital media protection. I was thinking of this in the car while listening to an NPR story on rockabilly. NPR does a good job with this. They offer (after a brief delay) plain-text transcriptions of the story, a podcast of the whole show as aired, and a bunch of links to listen to related stories and some of the music referred to in it. But how often am I disappointed? Weekend shows are often distributed by others, with restrictions including a total inability to download them. Much of the music in the story is unavailable for listening at all. And its not really hyper. Music is not linkable from inside the audio story. I think similar thoughts when using my PVR. On the off chance I accidentally see an ad, and want to pursue it, I have to transcribe it, sucking it in with my eyeballs and keying it somewhere else, probably on another machine entirely. This is true even for an ad for another show, where I have to search on the PVR, then type in the name of the other show. The systems are still glorified VCRs, with little or no awareness of the content (except the CCI-byte... hmm, again, no hurdles to getting DRM in place...) And why should this be? I am really not sure. Its trivially easy to come up with ways to monetize these sorts of interactions. Want me to watch the show? Auto-pop the search field with the ad info. Want me to buy your music? Let me listen to it stream, and link to an online store (or amazon if I must buy the CD). All in all, much more believable as a revenue stream than most internet technologies I see floating about.

Worst error message this week

Alison got some bad pillowcases from Garnet Hill, and was very sad because they are cool but fell apart in the first washing. Unusual these days, and we buy from them a lot. So, she fills in, at some length, the return form, and gets this: Let me count the ways this is bad:

• It's not that obvious it's an error message. Alison was frustrated at the page recycling for no clear reason, and had to look about a bit to find the new message.
• On recycle, the pulldown selection is lost. So I have to reselect it each time. Why? Is it secret info I wouldn't want to feed back to the browser unmasked?
• What's broken? She could not figure it out, even basically. I surmised from working with IT guys and fixing (or failing to fix) error messaging that its very literal. "Message" at the front is the field label. So I can disregard the rest of the fields. Highlighting or otherwise clearer labelling would be nice.
• Kanji?!?! In a word, WTF is that? I know, but really, who else does? Okay, I see the switch for "Customers in Japan" in the corner, so who reading the website in EN-US knows this? Not Alison, that's for sure.
• Why do they care? Why can't I use any character encoding I want? There's a Japanese version of the site, so double-byte characters can be stored in their datastore. And if not, just live with "unknown character" spacers. I see this all the time from people with weird emailers.

So, I quiz a little, and find out she typed it in Word to reduce the chance of loosing it, and spell check and so on. I find (pulling the content into a text editor, a few auto-recoded characters, like hree periods turned into ellipsis and so on. Eventually, I get to the heart. Its the apostrophe. On the fourth line, "can't." The one that the browser has rendered as a single quote just fine, somehow cannot be read in by the software as the correct character, or just disregarded as unknown, so I have to meticulously edit the content. We got it sent off, but its infuriating in its pointlessness and waste of code and resources.