I’m a big proponent of wireframing as a tool to create better interface designs. We recently released a mobile wireframing toolkit for keynote and powerpoint. The toolkit is not free but it compensates by extra amounts of awesome. More info here.
I’m a big proponent of wireframing as a tool to create better interface designs. We recently released a mobile wireframing toolkit for keynote and powerpoint. The toolkit is not free but it compensates by extra amounts of awesome. More info here.
I wish HTML could be the future of app development but there are a number of reasons it’s not there and unfortunately won’t be anytime soon.
To understand the problems we’re facing today with native vs. HTML we need to roll back the clock back to 1994. This was my first memory of HTML. I had just taken an intro computer class on basic networking and data structures. We learned about the efficiencies in how packets get sent and recomposed between computers and we also learned how to efficiently pack bits into a data-structure for optimal efficiency. Native C & C++ type stuff.
My next class was an intro to HTML. At the time HTML was pretty simple and you could count the core tags on your fingers <html> <head> <body> <p> <h1> <img> <b> <a> and <center> and <i>. We were able to create basic web-pages. Really basic, no CSS, no JavaScript almost all text.
Even back then I felt there was something wrong. At the core levels of efficiency of both data storage and network traffic it felt like there were problems. Where were the data-structures? To create something as simple as a link wasted 16 bytes <a href=”"></a>. No big deal? What’s 16 bytes anyway? 12 bytes too many.
Yes, it’s a little extra data. But it’s not just storage of the data but it’s encoding the data, sending it over the network and parsing it for display. The inefficiency isn’t on the one tag. It’s on every single tag. Same problem for network requests. Instead of opening a connection to a server and getting all images and data in one shot you would open a separate connections for each image.
Fast forward to 2011 and the problem getting clearer. Instead of a handful of tags and a couple images we have hundreds of tags, properties, images, css files, javascript files, web-fonts, DTD documents, etc, etc.
The twitter iPhone user-interface is, for the most-part, slick however there’s one screen that has a large number of interface complexities and design issues. For me the search screen sticks out. The twitter business model has shifted toward “trending” and “promoted” tweets while the UI has traditionally lacked a focus in theses area. As a result compromises have been thrust on users in the form of the #DickBar. This could have all been avoided if the search interface had properly incorporated trending and promoting terms as part of the core design.
Here’s the current version:
The screen is supposed to serve four core functions and several secondary functions.
In looking at the screen there are a number of problems and unusual UI patterns.
Proposed design:
The specifics of how search works within the twitter app are subtle and there are many nuances that are not listed here such as how results are pushed into the view or how search results are saved, displayed or edited. The key point I’m illustrating is that even complex interfaces can be made simpler and clearer while simultaneously improving the business value.
This is the first in what I hope will be a series showing basic UI explorations and critiques of various user interface screens, with a focus on mobile applications.
The screen I’m starting with is the FourSquare Places screen. The purpose of the screen:
Issues I spotted with this screen.
Quick re-design:
Looking for a little help from my readers. We’re working on an iPhone Wireframing design toolkit. Can you please take 3min and answer just five questions.
Update: The poll is now closed. If you’re interested in being notified when the wireframe toolkit is released please sign up here.
Google recently announced their plan to remove H264 video support from chrome’s use of the HTML <video> tag. This caused a lot of people on the internet some anger, tirades of evilness and more. I however view this in a different light.
Google can do whatever it wants to in its browser and if I don’t like it I can use something else. Even if Google wanted to kill H264 it would likely have little luck without at least the cooperation of another large operating system player like Apple or Microsoft.
Ultimately search traffic is more important to Google then video standards. If this change causes a shift in the former I expect them to back peddel on the latter. Even if WebM is a better format the right way to gain adoption is not by trying to force the format on web developers and consumers. If it’s that good Google should convince the Firefox team and WebKit teams to support it.
With the recent password failure of Lifehacker, Gizmodo, Gawker, etc. It’s should be painfully obvious to several million users that passwords suck and the various solutions for solving password hell are also pretty terrible.
Why are they so bad?
I’ll stop, perhaps you have your own reasons why you think passwords are bad. Let’s move on.
Every website that wants you to login:
The traditional approach has been to present UI on the screen to have you input this information and then ask you to re-enter this information anytime you want to login. Stupid waste of time. Don’t even get me started on Capchas.
The browser should know who I am. The browser should also know how much information I’ve agreed to share with any particular site. Yes, junior privacy is important. The website should never know my true password. Think of it like Facebook Connect. Perhaps “Browser Connect” where the browser will log you in.
Why is this better?
In technical terms this would likely be something like Oauth with the browser but I’d prefer that it be coined as NoAuth as the goal should be to make passwords suck less.
I’ve been working on iPhone apps for the past three years and more recently we’ve been exploring Android and iPad apps as well. These are my first impressions of a Blackberry Bold:
Operating system is very much file/folder based. Apps live in a folder, within folders. The interface has no labels unless you hover over an icon. This is particularly bad as most built in icons are mono-tone. This is a classic example of “Mystery Meat Navigation“What about the apps?
The apps that I explored were very inconsistent. Even across popular and built-in apps the UI was questionable and certainly not elegant. The developer strategy is confusing. If developers are worried about fragmentation the fear is much more real on BlackBerry then on Android. The platform actively sells multiple platforms, resolutions and capabilities:
Across these phones you’ll also find different capabilities across single lines of phones. This can make testing across devices to be challenging.
I think about BlackBerry in the same way that I think about Internet Explorer. You can’t ignore it as it has a non-trivial market share but part of you is rooting for them to go away.