#UX
-
Daring Fireball: The iPad Pro (daringfireball.net)
The user should never have to wait for the computer, especially if it’s just for an animation.
-
#indiewebcamp 2015-02-24 (indiewebcamp.com)
if you have bad UX, you only get the type of people who are willing to put up with it
-
@elfpavlik #IndieWeb focuses on:
#ownyourdata, own notes > tweets
#UX #design > protocols
More: http://indiewebcamp.com/principles (ttk.me t4_h2) -
Next up in interaction - Slashie (www.slashie.org)
If a tiny winch was stuck at the wrist with a super thin wire leading up to the tip of our index finger, it could simulate a surface by straining and retracting the wire at just the right time and thus giving haptic feedback in mid air. This would create an “air tap“, simulating a surface that doesn’t exist.
-
You should not be displaying relative dates
Every time I see a web app display a date as "30 minutes ago" I cringe a little. This was cute 10 years ago when rapid publishing on the web was new, but there are a number of problems with this.
Relative dates break screenshots
How many times have you seen a screenshot of a tweet that says "28 minutes ago"? Months later, you've completely lost the date of the tweet.
The only clue in this picture about when the tweet was posted is the copyright at the bottom of the page.
Twitter has since stopped using relative dates on their tweet pages, and instead just shows the full date now.
Now, Twitter uses the format "10:42 PM - 15 Aug 12" and will always display the full date, even if viewing a recent tweet.
Relative dates aren't machine readable
If you've just put a relative date in a tag, all of a sudden the date is not machine readable. If you insist on using relative dates, at least mark it up with the appropriate HTML5 element so there is a machine-readable version of the date.
<time class="dt-published published" datetime="2012-08-12T09:00-0700"> 12 hours ago </time>or, if you can't use the HTML5
<span class="dt-published published"> <span class="value-title" title="2012-08-12T09:00-0700"> </span> 12 hours ago </span>Relative dates are ambiguous when read
If you're looking at an email and it says "2 hours ago," how are you supposed to know if it's rounding the number or giving you an exact value? If it's currently 11:15am, was the email sent before or after your 9:00am phone call?
If it says "2 days ago" how do you know whether it was at 9am that day or 4pm that day?
Gmail solves this by including both the exact time as well as the relative time.
When viewing a thread of emails, Gmail uses a different format of date depending on how long ago the date is. If the date is less than 24 hours ago, it will show just the time. If older, then it shows just the date and a number of days ago.
As shown in this screenshot, the times from 10:25pm to 10:57pm all show the same "9 hours ago" text. The difference between 10:35pm and 10:49pm may be significant depending on the situation, and I would hate to lose that piece of information if all I saw was "9 hours ago".
What next?
In summary, avoid displaying relative dates, but if you feel like you absolutely need to, follow these best practices:
- Show both the relative date and absolute date on the page to provide more context
- Include the machine-readable version of the absolute date in an HTML5 <time> tag, or use the Microformats value-class-pattern
-
Things I don’t like about Twitter 4 for IOS (www.byte.org)
Don’t pay attention to what your users ask you for, pay attention to what they are trying to achieve.
-
Soft Signup: Lower the barrier to entry
Nobody wants to be presented with a signup form when trying out a new web service. Even though in recent years many websites have trimmed down their signup forms to make them easier to complete, I think we can do better.
A typical signup form these days consists of asking for your email address and creating a password. Some will also request you create a username, or ask for your real name.
People will probably fill out your signup form on your website if it doesn't look too daunting, but mobile apps are a whole different story. With mobile apps, people expect to be able to use your app immediately after downloading it. Adding a signup form will do nothing but make people frustrated. It is important to think about whether you actually need their email address or phone number in order for them to at least start using your app.
Incrementally collect information from your users as it becomes necessary to provide a feature.
Example: geoloqi.com
Download the app and press "use anonymously", you're taken to your map
You can leave yourself a Geonote, and we can deliver the message since we have your push token for the device
When you press "Share Location," you have multiple options:
Send via SMS or Email
The app opens the phone's system SMS composer, and your phone sends the SMS. We never need to know your phone number to do so.
Send via Twitter or Facebook
In order to post to your Twitter account, we need to connect your Geoloqi account to Twitter. At this point, we prompt you to log in to your Twitter account which then tells Geoloqi who you are. Similarly to Twitter, posting to Facebook requires you to grant Geoloqi permission to your Facebook account.
At this point, we have now named your previously anonymous user account in Geoloqi, tied to your Twitter or Facebook account. This is a relatively seamless way of "registering," since you knew exactly why you had to authenticate at that point.
Soft Create: GraphThis.me
Similar to the idea of "soft signup" is the idea of "soft create." Send an email to "weight@graphthis.me" where the subject line is your weight, and a graph will immediately be created for you. Replace "weight" with other values to create new graphs.
GraphThis doesn't require signing up beforehand in order to use the service, since you'll be inputting data from your email address anyway. If you want to expand your input options, such as being able to send a tweet or a DM, then you can connect your Twitter account.
GraphThis doesn't require that the tag "weight" be set up before starting to graph the values. It could have required you to set up the graph name before hand, but that would have increased the barrier to create new graphs.
Conclusion
Make it as easy as possible for people to start using your service. Think about whether you actually need more than a unique identifier for a user in order to get them started playing around. Collect new information from your users only as it becomes necessary to provide a new service to them.
-
A nice way to show Twitter replies inline: http://www.flickr.com/photos/aaronpk/4775035589/ I wish the main Twitter website did this! #UX
