As Ryan tweeted, this really is “condensed years of blog posts and project experiences into a 30-minute talk.”
So. Good.
Category: Web Apps
David writing on Signal v. Noise about building mobile version of Basecamp:
We implemented the main progress screen in the iPhone app in first a fully native version, then again in an HTML-backed version.
After a fiddling a bit, the conclusion was clear: There was no discernible difference! Well, except for the fact that it was far quicker to develop the HTML version than the native version.
Count me in for this approach.
Jakob Nielsen publishes an Alertbox:
People can use computer systems for years without knowing about features that would be very useful to them. This is true even for productivity applications that people rely on for their livelihood, such as email, word processing, and spreadsheets. In testing intranets, we frequently find that employees are unaware of key enterprise features.This seems like a paradox, because users would gain substantial benefits — potentially accrued over several years — if only they bothered to spend a few moments looking around the user interface. The ROI seems clear.
However, while users might have a mathematically true ROI from learning more about user interfaces, the ROI might not be so clear from a behavioral standpoint. The problem is that the investment occurs immediately: users must suffer the interaction cost of navigating through obscure parts of the user interface. In contrast, the benefit is deferred: users realize it only in small increments in some undefined future moments when they might use newly discovered features.
And then he provides tips on how to encourage learing. First among them: Fewer features.
Ryan Singer sums it up nicely. Some points I particularly liked:
The reason I am making a product is to give people capability they lack. That’s why they pay for it. The gap between the person’s current situation and the situation they want to be in defines value for them. They hire your product to do a job. The job is their definition of progress from here to there.
Some people think patterns are formal things written in a book or collection, but they aren’t like that. They are natural and spontaneous just like spoken language. We learn a language by hearing it and speaking it. Words, phrases, and constructions come to mind as if by magic.
This works against you when your work isn’t goal-directed. R&D projects and exploratory design don’t benefit from narrow problem definition. Platform and infrastructure projects are different in kind from product projects because the platform is meant to enable products on top of it, which are themselves targeted at specific situations.
I wanted to share five paragraphs of customer support conversation I’ve had with the rest of the team (two other guys). As I’ve IMed with one of the guys few minutes ago, I automatically went for the IM window. But first thing that stopped me was I remembered that sometimes the IM does not send longer messages. So I am thinking: “OK, there has to be some better way.”
Then it clicked: “Oh, wait, this is the sort of thing we have Basecamp account for!” And that led me to realizing one obvious disadvantage of abstract software.
Continue reading
Des Traynor writes for Intercom blog:
As Jared Spool notes, when teams are designing and building for themselves, they consistently improve the tasks that they do frequently but ignore the critical-but-not-frequent tasks.
He then proceeds to give specific examples. Good reminder.
Via @daeltar
FROONT seems to be worth playing with.
Hakim strikes again.
I think this could work.
The easiest way to create and share beautiful presentations.
It’s Hakim‘s project so you know it will be good.
Intuitive statistical calculators, ideal for planning and analyzing A/B tests.
Collection of the best articles, videos, presentations and other resources on large JavaScript apps.
Simple overlay instructions for your apps.
Think of it as a WordPress template but for your next web application.
Native views and web views are good at different things.
Native is good for high fidelity interaction, animations, responding to gestures. However the native APIs are bad for designing “documents” — that is, layouts where elements flow within a container and push each other around. That means that things that are extremely easy on the web can be painstaking in native UI without much upside.
Web views have limited interactivity, but they have other advantages:
* Faster iterations. You don’t need to push a build when a webview changes.
* Document-style layout, as mentioned above.
* Higher density. We found it easier to show more information on the screen with HTML/CSS than the native controls. Looking at other apps out there makes me think it’s an attribute of the medium, not just us.
* No need to sync data or duplicate logic. Sending HTML down the pipe is simple.
Finally yes, we get the multi-platform advantages because the web views are also served to people who hit the regular mobile web version of the app without any wrapper.
Via @keff85
Nice overview by Harry Roberts.
Via @sixrevisions
If you are in the business of building anything for users, you must watch this. For those of you who know her “Creating the passionate users” talk, this is an updated version of the theme.
Via @paveldolezal & @davegreiner