Established7 Days with Tweetie 2
After a week with Tweetie 2 for iPhone, I can say unequivocally that it is easily the best Twitter client available – mobile and desktop. It has a level of fit and finish that few apps achieve.
There have been other reviews of the app that go into depth on the features and quality so I’m not going to do that here. Instead I am going to take on the one large information architecture flaw I see in Tweetie 2. Let’s dig in.
TWEETIE MODES
Tweetie has basically two reading modes. There is the standard tweets mode which provides button bar access to your timeline, replies/mentions, direct messages and search. I’ll call this ‘tweet-view’. This is likely where you will spend most of your time. With the possible exception of search (which I’ll touch on more later), these are all related ways of viewing your incoming messages. This grouping makes sense.
Tweet-View Button Bar
The second reading mode is for profile-specific data. This provides button bar access to your own user profile, recent tweets, mentions and favorites (this is also where you view any other user’s profile). Generally speaking, this is the outgoing content from any user. This I’ll call ‘profile-view’. This set of functionality is also grouped in a fairly sensible way.
Profile-View Button Bar
But there is a problem. And that is the bridge between tweet-view and profile-view.
TWEETIE’S BRIDGE TOO FAR
The button bar in tweet-view ends with a three dot ‘more’ button ( ••• ). Tapping this button takes you to the ‘bridge’ – this screen is technically within the tweet-view mode (no change to the button bar). The bridge screen allows access to four things: My Profile, Favorites, Go to User and, slightly separated, Drafts.
More Button Leads to Bridge Between Modes
Here’s where it gets weird. The first two items take you directly into elements within the profile-view mode. Go to User takes you through a search mechanism but eventually dumps you out at a user’s profile page within profile-view. Drafts is completely separate functionality.
While this is all a little awkward, it is not a big deal. What makes it feel truly confusing is coming back from the other direction.
More Button Within Profile-View
Let’s say you are looking at your user info. This means you are in profile-view. In profile-view there is no ‘more’ button in the button bar that would take you back to tweet-view. Instead, you tap the More button in the header which takes you back to the previous page – the bridge screen. But the functions available on the bridge push you in the direction of the profile-view. You have to notice that the button bar has switched to tweet-view and tap the appropriate item you want. It’s confusing and counter-intuitive.When I go back to the bridge, I always end up hitting the Accounts button in the upper left (thinking I need to go further back to see new tweets) which takes me a step too far out.
Is this a major problem? Probably not. But for an app with as much polish as Tweetie 2, it’s a sore thumb.
Basically the issue is wether the profile-view should be treated as sub-pages or if it is an entirely separate section of the app. Right now it is an uncomfortable hybrid. If it is subpages, it should not have a button bar. If it is a separate section, it should not use a ‘back’ button in the header. I think two modes are deserved but how should they coexist?
From an architectural perspective, tweet-view and user-view are flip sides to the same coin. Tweet-view focusses around incoming content while user-view focusses on outgoing content. Therefore, the More button should act as a toggle – it swaps you between modes (without an in-between bridge step). This toggle would take the place of the More button in tweet-view and would be an additional button in profile-view (bringing it to 5 buttons as well). The two modes should be stylistically distinguished from one-another in some obvious way. Personally I’d like to see a white button bar in profile-view.
Problem solved? Almost. This makes switching between tweet- and profile-views simple and efficient but what about the additional functionality that the bridge provided? The Bridge had four elements: My Profile, Favorites, Go to User and Drafts. My Profile and Favorites are now handled more effectively by taking you straight into profile view – but where should Go to User and Drafts live now?
Go to User is a type of search and it makes the most sense to move it there. I would put it right between Search and Nearby.
Search Page Should Absorb Go to User
Drafts is a larger issue. Putting it in More seems to be a bit of a kludge to begin with as that page was a catch-all for misfit functions. Drafts is intimately tied to the compose message functionality. And that is where it should belong.
COMPOSE PERFECTION
Tweetie 2 has achieved a level of refinement in the compose window that truly is a step above. I tend to use the horizontal orientation for message composition and nearly all the Twitter clients are forced to cram in so many options that there is little space left to actually, you know, write. Tweetie cracks this problem by combining character count with an ‘advanced functions’ button.
Tweetie's Clean Compose Screen
The advanced functions button allows access to 6 key features which are hidden “under” the keyboard:
Tweetie's Hidden Compose Functions
Without a doubt, these are vital functions for the average Twitter user. You may use some of these features every day and some not-so-much but I don’t think any could be considered useless and therefore removed. However, Shrink URLs is something that could (arguably should) be done automatically. This would free up one function tile which could be replaced with Drafts. Now Drafts would be located within message composition which makes more sense than putting in a random catch-all location.
YET…
There is one thing that still bothers me. Searching for users can only be done through the tweet-view mode. Above, I moved Go to User to live within the Search screen but even before that, Go to User was located under tweet-view’s more button. I think both view modes should have identical access to search. Unfortunately the profile-view mode has no room for for additional buttons in the bar and I don’t see any other locations to put it. I would love to hear ideas on this one.
In closing, I want to reiterate my appreciation for Tweetie 2. It is an excellent piece of software. I think it just needs the level of refinement you find in the compose message screen to be applied to the confused mode switching functionality. I know I’ll see the fit and finish become more refined as Tweetie develops.
Bundle Up
Great quick Atlantic piece by Megan McArdle discussing Apple’s iTunes/iPod/iPhone “monopoly”:
But, you say, you’d like to buy music from iTunes and play it on a Zune? Well, I’d like to get takeout from Ray’s Pizza and enjoy it in the stunning ambience of Cafe des Artistes. If the waiter refuses to let me do so, is that a monopoly?
Just cuz a pea comes in a peapod doesn’t make it a monopoly.
Video in the browser
Ars Technica is reporting on Apple’s new proposal for a new HTTP video streaming standard. Its interesting that this comes so closely on the heals of the debate over the implementation of the <video> tag in the modern browsers. The issue in that debate, which I discussed recently, is that Firefox supports the Ogg Theora video codec due to its openness while Safari supports the h.264 codec due to its quality advantage and support from hardware decoders.
This streaming standard would be based upon an MPEG2 stream which could contain h.264 for video and AAC audio. This is an alternative to the existing standard Real Time Streaming Protocol (RTSP). RTSP needs its own server software and operates on a different port than HTTP. This means that it can easily end up blocked, purposefully or accidentally, from standard web traffic.
Content delivery networks (CDNs) like Akamai must also manage servers specifically for managing video that are separate from their HTTP caching servers. I dealt with this when I ran the web department at MGM Studios. We initially used Akamai and eventually moved to Limelight since Akamai is outrageously expensive. Regardless, at both vendors, HTTP caching is automatic after the initial set up but video files must be directly uploaded to the CDN’s servers (rather than the web host’s) and URLs must reflect that. This is just a complicated system overall. From my understanding, Apple’s proposal would allow content to be uploaded to the main web host then automatically cached by the CDN as if it was any other HTTP element. This would be an efficiency gain for site developers, lower cost for the CDN and be more reliable for end users.
There is a “but” however. The drawback is that HTTP delivery of video files would be in chunks. One long video would be divided up into parts as small as 10 seconds or so. While this would not be known to the end user, the video player would be consecutively playing parts of the overall video. This is great for bandwidth reasons. Servers would only deliver the necessary 10 second chunks, not the entire video. On the server side though, this would mean that a web video wouldn’t be a single file; it would be a file for every ten seconds of video. Suddenly managing files becomes a headache. Also, live video would operate on a ten second delay as each file is created and added to the stream.
Overall I think this is a good direction. It would be more efficient most of the way around and all it really needs is a way to manage video files encoded for it. It’s nice to see Apple proposing it as a standard and I hope that more vendors jump on the bandwagon.
I’m curious to see why Apple is making such serious moves for in-browser video improvements. Efficiency improvements are great but they impact big video sites the most. Apple delivers very little video compared to YouTube or Hulu. Why do I feel that somehow this is all tied to the future of the iPhone?
Augmented Reality
A new post on Engadget talking about TAT’s (UI designer for the G1) new augmented reality concept. Check out the video below. Now this certainly may make a better tech demo than real world application but man is it interesting to watch. Nice that it allows a simpler mechanism for discovery of people’s public profiles. Anyway, well worth a watch:
Chrome OS = Meh
Much discussion over Google’s announcement of its forthcoming Chrome OS. Is this the full announcement of war with Microsoft? Is this going to shake up the whole industry?
Nah.
In the short term (which means when Chrome OS launches in late 2010), the OS is planned for use on netbooks. This is a perfect match for a web dependent OS. Those devices are low powered and typically run Windows XP since they don’t have the specs to effectively run Vista or Win7. So it is a daring new competitor in a market segment that buys old Microsoft software.
The bigger issue is that we are turning a corner on the value of software (not necessarily the OS). Chrome OS is going to provide productivity applications through Google Docs. This will be the first attempt to see if users would be happy with a non-desktop approach to software. Certainly now you can do all kinds of productivity, photo editing and content sharing through online options. But right now these are just that – options. Not the sole method for tackling the problem. Will users be happy with a free but online only solution for basic work. That’s what we’ll learn.
This is more of a shot across the bow of MS Office than of Windows proper.
Dear Apple
I want iTunes to sense my iPhone when I get home and if it is playing music, to switch playback to my iTunes output.
This would be a great start to “intelligent assumption” communication amongst devices.
OK? Thanks.
Keys & Batteries
John Gruber over at Daring Fireball has posted an insightful piece on mobile phone keyboards.
John recognizes the key decision that Apple makes in the design of their products:
Apple tries to make things that many people love, not things that all people like. The key is that they’re not afraid of the staunch criticism, and often outright derision, that comes with breaking conventions.
This is brought up in reference to not only the soft keyboards but also the increasing use of sealed batteries that Apple is using across its iPod, iPhone, and Macbook lines.
To me the greater point is that Apple deeply believes in products devoid of moving parts or even the ability to detect that they are made out of individual component pieces. This benefits Apple is several ways. Not only does this foster products that have a level of refinement above most competitors but it also decreases the number of mechanical failures that are inherent to moving parts while also removing the costs in designing and assembling products with this added complexity.
The future, I believe, is going to be made of software keyboards. It simply offers more flexibility. A single device can be deployed worldwide with software keyboards automatically displaying the appropriate format for the user’s language.
Are soft keyboards completely ideal? Probably not. But they offer more pros (flexibility) than cons (no touch typing) when used in low typing applications. Much like the qwerty keyboard format that grew from the limitations of typewriter technology, soft keyboards are not perfect but they are better than any other option and we can only build upon the best we have at the time.
I predict that Apple will ship the first glass keyboard for desktop use. This may not be for a while but it will happen. Simply because it will allow more people to have more flexibility in their interaction with the computer which will allow more multitouch editing features on the mac. People who do a lot of typing will stick with keys and that’s fine. But people who do more with photos and video and the web will find a lot to like.
<video> on Pause?
Ars Technica has posted a very good summary of the debate over the HTML5 <video> tag which allows video to be played back without the proprietary Flash plugin: Decoding the HTML 5 video codec debate – Ars Technica
I particularly like commenter mpat’s prediction for how this will likely play out:
The way it’s going, Youtube will use H.264 as its primary source, because that’s the only thing that will run acceptably on mobile platforms, and use Flash as a fallback, because nothing else will work with IE. This means that Safari and Chrome will run Youtube better and cooler than Mozilla, which will still get Flash. Even sites that do use Theora will run better on Safari and Chrome, once the appropriate plugins have been installed. I just can’t see how Mozilla can ever win this.