Categories
Web Technology

Re-Thinking Browser Buttons

A prediction: In the near future, browsers will no longer have stop and refresh buttons.

Think about it. When the internet first started out, pages actually took a human-measurable amount of time to load. And with finicky dial-up connections, it wasn’t uncommon for a connection to completely drop in the middle of a page load. It made a lot of sense to have a refresh button, in case you just lost your connection and have now reset it. Stop made sense too; if you saw a page loading tons of images, maybe it wasn’t worth loading at all.

Now fast-forward to today. Pages load instantly, and connections are almost always persistent. No more need for refresh, no more need for stop. The buttons are obsolete.

Testing the Theory

Looking at what buttons in my toolbar I actually use (I’m running Firefox), There are really only four:

  • Address Bar
  • Search Bar
  • Back
  • Forward

The buttons I don’t use are:

  • Stop
  • Refresh
  • Home

So to see if I really don’t use them, I removed them from my toolbar about a week ago. And you know what? I haven’t missed them one bit. They don’t fit into any of my use-cases anymore. We simply don’t need stop/refresh as much as we used to, and even home is less necessary than it was in the days of online portals.

In fact, I’m really starting to appreciate my minimalist toolbar. Back/forward on the left, then address bar filling up most of the screen, and a search bar off to the right. Nothing I don’t use every single day. It’s bliss.

A Note for Web Developers

Web development is one case where refresh — as an action — is still necessary. I still maintain that a refresh button is not needed in this case. Web developers are always power-users, and we simply don’t use buttons for actions like refresh; we use hotkeys.

If you’re a web developer, you probably at least use ctrl+R or F5 to refresh a test page. Better yet, you probably use ctrl+shift+R or ctrl+shift+del and some menu work to clear the cache before a refresh (and if you don’t, you should). Standard refresh buttons aren’t ideal for us anyway.

Browser “Support”

Obviously not everyone will be willing to part with legacy buttons right away. One interesting solution to this problem is customizable toolbars, such as the one used by Firefox. Here, the user has full control over what buttons appear in the interface. This is in fact the only browser I tested that allows the stop/refresh buttons to be removed.

There are also a couple of major browsers that have started to deemphasize the stop/refresh buttons. Chrome, for example, combines them into a single button, and Safari goes one further by merging this single control into the address bar.

Predictably, Internet Explorer is still a step behind. Microsoft’s browser’s UI is generally recognized as the weakest of the four, though it looks like they are catching up with IE9.

I didn’t spend much time digging into more niche browsers. If anyone uses one, I’d be interested to know how the UI stacks up against “the big four”.

What do you think? Am I out in left field here, or are we about to see a neat evolution in the web browser interface?

Categories
Web Technology

Windows Phone 7

The other day my boss walked up to my desk and asked me to choose a number between one and ten. I said four. He handed me an HTC Surround, a new handset running Windows Phone 7, and told me to try it out for the day.

It was awesome.

This is the first serious iPhone-competitor I’ve seen so far. Sure, it doesn’t have Android’s openness or Palm’s lovable WebOS, but it has it’s own user experience that isn’t just a knockoff of what Apple came up with almost four years ago. Here are some thoughts from my day of usage:

I’m in love with the interface.

The new hub-scrolling paradigm is a fresh and welcome change to how content is organized on a small screen. Instead of always breaking different information into distinct views, like you would see on an iPhone or Android phone, applications for WP7 are organized as one giant view that you sort of scroll around on. It’s a bit tricky to visualize, but once you’ve used it, you get it. It’s that simple.

And then there’s the transitions! They’re incredible. Anytime you do anything on the phone, it’s accompanied by a fancy-but-not-quite-distracting animation. The way one view flips to another is gorgeous. The loading screen is clean and fun to watch. The whole thing is like one giant production, and it’s really well done.

Lastly, many of the applications I downloaded already use these new UI elements very well. The Facebook app (which admittedly was made by MS) is easy to use and well-organized. Though it’s completely different from the iPhone Facebook app, which I’m a huge fan of, it’s just as good. I was blown away. Twitter was another great example, and this was actually made by the guys at Twitter. They grasped how to use the new graphical features and made an absolutely stellar app out of it — again, totally on par with Twitter’s official iPhone app.

The hardware is good, but not great.

The Surround in particular had a slide-out speaker, and a built-in stand. While this is probably standard fare for Android users, as an iPhone-enthusiast I’m not used to my phone having weird hardware. I probably wouldn’t use the speaker/stand much, but it might be interesting to see what other kinds of hardware are added in future third-party devices.

Of course, the standard components were done pretty well. The camera quality (5 MX stills, 720p video) is the same as that of the iPhone 4 (and puts my 3G to shame), though there’s no flash and no front-facing camera on this particular handset. The screen quality was very crisp, though I didn’t have an iPhone 4 on hand to compare it to.

It could be interesting to see how the hardware powering future WP7 devices will stack up to the iPhone 4 and whatever new iteration of the iPhone that Apple releases in 2011. For now, the iPhone still comes out on top, at least from the stock of WP7 devices available in Canada.

Some other misc things I liked:

The soft-keyboard is pretty awesome. The shape of the keys are different from the iPhone, and I found I was making less mistakes while typing. That said, the auto-complete may be a step down. Instead of filling in new words by default, like the iPhone, WP7 tries to guess what you’re typing as you go, and you have to manually select it when it shows up at the bottom of the screen. This is decidedly more work on my part; not only do I need an extra tap to auto-complete, I also have to constantly peek down at the bottom of the screen to find it.

Finally, I need to mention the home screen. I like it. Having applications update their icons automatically with new information is very useful, and grouping content by subject rather than by application has a lot of potential. The People tab, for example, lists all of your contacts, and integrates Twitter/Facebook information if applicable. I didn’t really have enough time to get a good feel for how useful this really is, but it’s an innovative concept nonetheless, and I’m anxious to see what third-party developers will do with it.

I kind of want one of these phones!

The overall impression I got from the Surround was quite positive. My current carrier-contract expires in July 2011, which should be right after Apple’s next iPhone iteration. I’m excited to see how WP7 stacks up at that point, because it looks like I might have a difficult decision on my hands — and that’s a good problem to have.

Categories
Customer Experience Web Technology

User Experience Begins at Step One

For this week’s post, I decided I would play around with the Internet Explorer 9 beta and post some initial thoughts. I’m a bit of a browser geek, and as I mentioned back in April, I’m excited about IE9. I imagined I’d have a great time exploring the support for HTML5 and CSS3, and playing around with new features like SVG and GPU-acceleration.

As it turns out, I didn’t get that far. Why, you ask? Two reasons:

Reason #1: It has never taken me as long to download a browser as it took me to download IE9.

Seriously. I opened a text file to log my initial impressions, and thought it would be fun to start taking notes right from my search to download the beta. I ended up saving my text file, happy with my outline, after only completing the install. Briefly, here’s what I noted:

Downloading the installer feels like work. The top hit on Google for Internet Explorer 9 is the old platform preview page from April, still with the same title. I initially skipped over it, thinking that I already have the preview and that’s not what I’m looking for. The next few results were all sketchy, unofficial mirrors. Eventually I crawled back to the preview page, which had a link to “Get the Beta”.

This led to a completely different-looking page (neither were particularly well designed, they were both quite startling in their mediocrity). Here I immediately saw a link called “Get it Now”, which I followed to a third page, that had not one but almost forty buttons labeled “Download”.

Yes, forty.

This is because Microsoft decided to list all languages IE9 is available in, each with its own download link. And to choose your preferred language, you don’t click on the language or a checkbox or anything, you highlight your OS version from the accompanying drop-down list. Are you kidding me? Who designed this? That’s five clicks now, for those of you who are counting, across three pages, with two different types of controls, and I had to parse my language out of a giant list.

Downloading a browser shouldn’t feel like a chore!

Think about the last browser you downloaded. Was it Chrome? Then you probably don’t remember downloading it at all, because it takes about 10 seconds. The download page can be found in an instant, and you click one button to download the installer. ONE. From one page, that you found really easily.

Maybe your last download was Firefox. In that case you probably remember it a little better. The procedure was smooth and enjoyable; branding was consistent and the sequence of clicks and navigation was concise and straightforward. You probably noticed how beautifully designed Mozilla’s website is.

If Microsoft is expecting IE9 to compete with the other major players in the browser market, they have to streamline the downloading process. Google and Mozilla go out of their way to make sure their browsers are easy to find, and simple/enjoyable to download. Finding and downloading IE9 is currently a hassle.

Reason #2: Installing IE9 is about as modern as debugging IE6.

I’m serious. The installer for IE9 looks and feels like it was built in about 1997. It’s a standard dialog box with a progress bar. No decoration of any kind, and no branding. No “Thanks for participating in our beta!” or “Here are some of our new features…”. Just the bare minimum; something no other browser maker would dare do these days.

And how long it took! I’m pretty sure I could have installed FF, Chrome, Safari and Opera in less than the amount of time it took to run the installer for IE9. Of course, Microsoft was kind enough to provide me with a couple of helpful progress messages explaining what was taking so long:

  • “Installing required updates.”
  • “Installing.”

That’s it. Two extremely vague statements with no way to gain further information. And just when I thought it couldn’t possibly get any worse, I completed the install only to find a pop-up telling me to restart my PC. I almost fainted. Why on earth would installing a browser require a system restart? This is unheard of.

Is this really the best Microsoft could do?

Where were the interaction experts that put together the interface for Windows Phone 7 or Windows Live? When will Microsoft figure out that it’s no longer acceptable to phone in their UX? That it’s not okay for even trivial interactions with a new product to be poorly designed?

The web crowd is not known for its patience, and I wonder how much longer it will persevere.

Categories
Web Technology

Make Web not War

I spent yesterday in Montreal at Make Web not War. It was a really fun time, and I learned a lot of neat things and met some interesting people. I was tweeting about it a fair bit, as were many others, (#webnotwar was actually the top-trending topic in Canada for much of the day) but for the benefit of those of you that don’t follow me on Twitter, I thought I’d sum up the experiences I had while I was there.

The keynote was a good start.

Joel Perras gave a great opening speech that really set the tone for the day. There were a lot of thoughtful tidbits about how closed-source platforms and open-source platforms can interact with one another, but by far the most-quoted phrase from this introduction was the following:

Interoperability isn’t a feature. It’s a requirement.

This simple sentiment sums up exactly what Make Web not War is about. Different platforms must interact with one another to be part of the modern web.

Next I saw a crazy-looking WordPress development process.

Morten Rand-Hendriksen develops WordPress applications, but he does things a little more radically than most people. He uses Expression Web to make presentational changes through a GUI, rather than editing CSS himself, and the speed of results was pretty remarkable. This was a really thought-provoking presentation, and lucky for you, some of the content is available on Morten’s blog.

Morten also shared a bit of interesting WordPress knowledge. Did you know that WordPress 3 (which is currently in Beta 2) will support custom CMS-style menus? The interface for it is very slick; select what you want, and drag/drop to set the order (no more HTML-level changes). Secondly, he found a really neat hack for creating custom template pages per-category: simple add a page called categoryName-categoryId.php and it will be used by WordPress for that category’s landing page. Lots of potential here!

Then there was a really interesting panel about communities.

The panel set-up was very informal, and provided a great atmosphere that really made it feel like we, the audience, were simply listening in on a conversation between the panelists. It’s hard to describe what I liked so much about this particular panel, but from what I remember, the take-aways were something like this:

  • In the world of web development, the community is your best friend.
  • In order for the community to grow and remain healthy, people have to participate.
  • Waiting for the “big” meet-ups that happen every four or five months isn’t good enough.
  • All big cities have a variety of technologically-inclined groups that meet up much more often than that.
  • The meet-ups don’t even have to be techie; a karaoke group or patio night is just as productive.

So the message overall was pretty loud and clear: get out there and spend some time with others in the web development world, doing anything from talking about new technologies to trading bacon-themed recipes.

After that, there were some five-minute web-app demos.

The one in particular that caught my eye was the not-very-carefully-named Flockoo. This is a service that allows you to log in with your Twitter account and enter a location, and then returns a list of all the users you follow from that location. Very useful for conferences, for example.

My favourite panel of the day was actually about SEO.

Man, was I shocked. I went into this one thinking it would be a drag (I have a relatively low opinion of self-proclaimed SEO-experts) but it turned out to be absolutely full of practical, useful information. The speaker promised that the slides would eventually be available via SlideShare, and I’m anxious to give them a re-read. They filled in quite a few gaps in my SEO knowledge, and I’m sure they’ll help you too.

Next was another panel, this one about cloud computing.

I’m not much of a cloud-guy yet, so I didn’t really gain much from this session. The only thing I distinctly remember was one of the panelists describing the current state of your average cloud-based service as a “cloudsterfluck”, which is a term I’m sure I’ll re-use for months to come.

Then I was pretty disappointed with the HTML5 session.

This is a topic I know a lot about, and I was really looking forward to seeing some interesting demos or cool new techniques. Unfortunately the speaker spent most of his allocated time rambling about spec changes, something that I (a) could have learned about myself in about half that time, and (b) was already intimately familiar with.

He did mention HTML5 Doctor, though, which is a fantastic resource for all things HTML5, and I made a point to share this awesome HTML5 demo with the other attendees via Twitter, as it’s my favourite HTML5 application to date.

The CSS3/jQuery session wasn’t much better.

The material wasn’t quite so dry, and the presenter was much more animated, but there still wasn’t anything really new or interesting.

Finally, there were the Coding Competition finals.

This is where the very best of two-dozen-or-so web-apps were shown off by their developers and voted on by their peers (the other attendees). The criteria for these submissions was that they used PHP, open data, and/or Microsoft Azure.

The entry I voted for was TaxiCity, a really creative game that uses geographical data from Vancouver to overlay a 2-dimensional game world on top of the Bing maps for Vancouver where you, the cab driver, drive around the city picking up and dropping off fares. The execution was very well done, and the distributed team clearly worked very hard to put a lot of polish into their product — an A+ in my book.

The idea that won, however, was an application with a lot of potential called Find a Home. This is a real-estate-type tool that lists homes in the Edmonton area and ranks them by novel criteria such as family-friendliness (based on proximity to schools and parks) and safety (based on proximity to Fire and Police departments). It’s certainly a good use of open data and new technologies, but I felt it wasn’t quite “finished” yet, even by alpha standards.

All in all, Make Web not War was a great time.

The food was delicious and plentiful, the venue was gorgeous, and the staff were fantastic. I’ll definitely go back next year.

Categories
Web Misc Web Technology

The Content-Sharing Problem

The rise of ubiquitous social networks has lead to a choice I often have to make: When I find something cool online, where do I share that content?

In the pre-MySpace days, when social networks weren’t really a “thing”, the decision was easy because there were only a small handful of choices: you instant messaged or emailed it to a few close friends, or if you were “that guy”, you forwarded it to everyone you knew. Fast-forward to today. If I find a cool link, I have all kinds of options:

  • Tweet it.
  • Share it in Google Reader.
  • Share it on Facebook.
  • Link to it on Yammer.
  • Post it on LinkedIn.
  • Send someone a private message through any of the above services.
  • Blog about it.
  • etc.

Which do I choose? If I only post the link in one place, I’m only reaching a subset of my total audience. But if I post the link in several places, I’m guaranteed to spam a few users multiple times. This dilemma is what I call the content-sharing problem.

My solution so far kind of sucks.

What I do right now is painstakingly case-by-case. If it’s particularly techie, it goes to one of the more techie networks: generally for something short and easy to digest, that’s Twitter, and for something longer, Google Reader. The idea here is that I want to match the content I’m sharing with other pieces in my friends’ feeds that are about the same length.

If it’s not techie at all, I’ll usually involve Facebook. Facebook is the venue that has the least overlap with any other network, and since I can post it on a specific friend’s wall, I can target that audience even more deftly. Since there’s unlikely to be much overlap, I’ll often share this again on Twitter or Google Reader, especially since they’re public and more persistent.

If it’s something work-oriented, that’s where LinkedIn and Yammer become more attractive. Unfortunately, these areas tend to have a huge divide in that many of my Twitter/Google Reader followers are also connections on LinkedIn/Yammer, and many are not. This is the most problematic situation, because I either don’t reach several people I care about or show a similar subset of people the same link twice.

I could go on, but you get the idea — it’s a mess. It’s case-by-case, and it’s probably NP-complete. It’s killing me.

Is there a better way?

So far, I can’t think of one. Even convincing everyone I know to follow me on one monolithic feed isn’t ideal, because with so many diverse people in one venue, my signal-to-noise would be different and probably pretty weak for each individual contact.

I’m grasping at straws here. Is there a technological solution to this that I could be using? Are there content-sharing etiquette rules that I should be aware of? Am I simply trying to be in too many places at once?

What do you do? I’m dying to know.

Categories
Web Technology

Internet Explorer 9

I’m a little late to the party on this one, but I have a few of thoughts I’ve been meaning to jot down since watching Microsoft’s MIX presentation about Internet Explorer 9. It’s a pretty in-depth video, and a touch long (~1 hour), but if you’re at all interested in browser technology it’s absolutely a must-watch.

Internet Explorer is no long playing catch up.

The resounding vibe I get from the video is that the Internet Explorer team is finally starting to get really serious about modern browser technologies. I’ve made my position on IE8 clear in the past — namely that it nailed CSS 2.1 but still wasn’t a competitive browser overall — and IE9 looks to be where that second clause will change. For the first time in about 10 years, Internet Explorer is innovating. For the skeptics out there, here’s a list of the features promised in IE9 that I’m excited about:

  • Proper JS/DOM programmability.
  • Standards-compliant HTML5 and CSS3 support.
  • GPU usage for more complicated UI effects.
  • Inline SVG support.

Now those first two aren’t exactly revolutionary, but it’s clear after the CSS 2.1 push in IE8 that the Internet Explorer team isn’t ignoring the standards anymore; they’re dedicated to promoting cross-browser mark-up, and they have the technical capacity to make it happen. This is great news for users and especially great news for developers, and hopefully it will push other browser-makers to fulfill their obligations to HTML5 and CSS3 as well.

What is new are those last two points. Using the GPU for rendering complicated UI effects such as the <video> tag is a welcome innovation to balance increasingly client-heavy rich internet applications. I can see this being a major reason for users to stick with IE9 (the first one in a while, in fact). And what is there to say about inline SVG other than finally? As long as the implementation isn’t falling apart at the seams I can see developers jumping all over this; I wouldn’t be surprised at all to see Firefox et al follow suit with similar support in the near future.

This is going to be huge.

IE9 is going to be the best version of Internet Explorer since IE4. It’s not going to be a standards-scoffing, security-lacking, feature-stealing deviant like its distant predecessors, and it’s not going to be that browser that we all hate rewriting our mark-up for. As a web developer who has lamented the existence of Internet Explorer for the majority of my career, I’m as surprised as I am pleased to say that for the first time in my life I’m looking forward to the next version of Internet Explorer.

Categories
Software Development Web Technology

Improving Performance in Flex and Scaling BlazeDS

I gave a talk today at work about Flex and BlazeDS, and in particular how to scale both to perform well during high-volume, real-time communication with a Java-based server (in the area of thousands of messages per second). Here are the most helpful bits from my presentation and the ensuing discussion:

Stick to StreamingAMF.

When it comes to real-time data transfer, StreamingAMF is really your only choice for a high-performance endpoint. It offers two simple advantages:

  • Streaming connections allow for true push, rather than less-effective fast-polling.
  • AMF is a binary protocol, so less data is transferred across the wire.

If you need a more thorough round-up of endpoints, I highly recommend DevGirl’s excellent endpoint explanation.

Batch messages going through BlazeDS to save bandwidth.

BlazeDS adds significant overhead to each message sent across the wire. With thousands of messages per second, this adds up to a very significant amount of bandwidth usage, to the point that performance will be adversely affected.

To compensate for this, buffer consecutive messages together and send several at once. Even a simple timeout that buffers message content for 10ms before sending it all as a single message will save an incredible amount of bandwidth, and a smart buffer that adjusts its timeout based on message activity will do even better.

This is easy to implement, and likely the biggest performance optimization available in a high-volume situation. Definitely worth doing if bandwidth and performance are a concern.

Override default BlazeDS connection settings.

BlazeDS sets two interesting connection limits too low:

First, the <max-streaming-clients> property is used to limit the number of clients that can simultaneously stream from the same server. BlazeDS limits this to 10 by default, so if 11 users connect to your application at the same time, that 11th one won’t get through. This is a serious fault, but we can raise the limit as long as we’re smart about how high we set it.

The reason there is a limit at all is that all connections in BlazeDS use blocking IO. This means that the maximum number of connections Blaze will support is limited by the maximum number of threads in the application container, since it will always require one thread per connection. Fortunately, modern containers support much more than 10 concurrent threads; Tomcat 6, for example, reserves 150 by default and even that can be boosted.

So the rule of thumb here is that you don’t want your connections in BlazeDS to outnumber the threads in your container, and that’s what you should base this limit on. If you require more than a few hundred concurrent connections, you’re out of luck and you’ll have to either wait until Blaze implements non-blocking IO connections, or upgrade to LiveCycle.

The second, much-less-serious configuration is the <max-streaming-connections-per-session> property, which is used to limit the number of concurrent streaming connections a specified browser can support. If this number is exceeded, new connections will not open on the same client. BlazeDS defaults this value to 1 for all browsers, so if a user opens two instances of your streaming app at the same time, on the same machine with the same browser, the second instance will not open.

This limit is dependent on the browser, and many do actually have a hard limit of one single streaming connection at a time. However, newer versions of Internet Explorer/Firefox/Safari, most versions of Opera, and all versions of Chrome support multiple concurrent streaming sessions. To take advantage of this, override the limit in your services config; I’d suggest looking at Patrick Heinzelmann’s awesome RemoteServices example to grab the specific browser numbers and a nifty code sample.

Get low-level with Flash Player.

There are probably a lot of neat Flash Player performance hacks that I’m not aware of, but here are two I’ve figured out so far:

The default frame rate in Flash Player is not very high. I’m not entirely clear on what it is; I’ve seen some sources say 24fps, some say 12fps, and some say it’s completely dynamic. Depending on what you’re doing, you may consider boosting it to draw more often. In particular, this can lower the worst-case latency between a message being triggered, processed and displayed. The flip-side here is that a high frame rate will raise your CPU usage, so that’s a trade-off to keep in mind.

Secondly, for the longest time I was updating the screen whenever I had new data to display. In retrospect, this was ridiculous. How do I know if I’m updating more often than the screen is being refreshed? How do I know how long it will be until this update is actually blitten* to the screen?

A much less naive approach is to make screen updates on the ENTER_FRAME event. This is dispatched right before Flash Player refreshes the display, so it ensures that whatever you do here will be instantly reflected on-screen. As long as this is the only place you’re doing screen updates, you know that you are doing exactly one update per screen refresh, which is ideal provided you’ve calibrated your refresh rate to match how often you receive updates.

The Profiler is your friend.

After all the above tricks have been exhausted, if you still need a performance boost, there’s always code-level optimization. Things like unrolling loops and minimizing allocation using the “new” keyword will add up eventually. A good way to find out which areas will benefit most from such refactoring is to use the profiler that comes with Flex Builder.

The profiler will allow you to view object allocation stacks and method performance. The former is a great way to find memory leaks and the latter is fantastic for finding out which methods are the slowest and thus most qualified for optimization. If you have any curiosity at all about this sort of thing (and you should!) I heartily encourage you to open up the profiler and fiddle around with it a bit; it takes a bit of ramp-up but once you have it figured out it’s a totally indispensable tool.

Hopefully this will be helpful to someone out there. Flex and BlazeDS are both very well documented by Adobe, but these were the handful of cases where I had to go well out of my way to find workable solutions.

* blitten: Past tense of blit.

Categories
Web Technology

Bears, Skittles and Google Buzz

Google Buzz is like a laser gun that turns bears into Skittles.

That’s what I tell people when they ask me about Google Buzz. Much to my surprise, even without any further explanation they’re often less confused than they were to begin with. That alone tells you something about Buzz (it’s purpose is murky at best) and something about me (I’m clearly great with similes). Once you get past that, though, there’s some truth to it (really!).

The basic idea is that you can think of specific instances where it would be really useful (such as: you’re about to get mauled by a bear), but in general it’s completely useless. You can go way out of your way to find a good use case for Buzz, much like you can drive out to a forest inhabited by bears and spend all afternoon tracking one down, but that’s not how I like to spend my afternoons or my time online.

The problem I see with Buzz right now, is that it’s not as powerful as Google Reader, Twitter, or any other social tool, and it doesn’t offer any compelling features to help early adopters attract the masses. I’d simply rather read status updates and find neat links through other web venues. That’s not to say that Google got everything wrong here, and it’s not to say it has no potential — there’s just not a whole lot to like about Buzz right now.

What I would do with Buzz.

I think Buzz should aggregate everything from all my existing web communities, and let me filter it per-person.

If I’m wondering what my friend davefp is up to today, I should be able to pop into Buzz and instantly see any content of his that I can access in any of our mutual online spaces. His Twitter, Tumblr, Google Reader, blog; anything he’s got going on that I could check in each of those tools individually, right in one place. That’s when I would start Buzzing like a bee (again with the similes — sorry).

Obviously, it’s not easy to set up that sort of scenario, and you could argue that this is what Buzz is trying to do and that it’s just a few (light)years away — but the APIs exist for this! It’s just a matter of stitching them together in a way that’s coherent and seamless, and doesn’t take very long to set up, even if I have a lot of contacts on a lot of networks.

So that’s my take on Buzz. Now if you’ll excuse me, I have 8 different networks to dip in to, and some Skittles to snack on…

Aside: have you seen skittles.com lately? You should check it out — we need more designs like this.

Categories
Software Development Web Technology

Software is all about Context

Context is a very important factor in software development. Knowing the conditions under which your software will be used is an integral part of crafting a positive experience for your users. Many companies take this to heart and create truly engaging software that really connects with its users, but the vast majority miss the mark. While I’m sure I’d have no trouble pointing out a myriad of context-related issues in software made by Average Joe Developer, today’s focus will be on showing that even the top names in software aren’t perfect.

Exhibit A: The iPhone’s Clock.app

Let me tell you a story. A few weeks ago, the fiancée and I were scheduled to meet with a potential wedding venue early Saturday morning. Given that it was a bit out of the way and we tend to oversleep, we thought we’d be smart and set an alarm using the iPhone’s default clock app.

So Friday night, we set an alarm thinking it would wake us up Saturday morning. It did not; it turns out the alarm we set was for weekdays only! While this was entirely our fault, I’m still going to call Apple out on not taking context fully into account: when we set the alarm, why didn’t the app warn us that the alarm wouldn’t go off the next morning? I would imagine it’s very rare that anyone sets an alarm more than a day in advance. It’s much more likely that when someone sets an alarm at night, they expect it to wake them up the next day. This is a case where a neat feature is actually an annoyance because context isn’t handled as well as it could be.

Exhibit B: Google Maps

Continuing our story, while I was frantically trying to get ready I was loading Google Maps to get directions to our appointment. After punching in the address and asking it to route us there, Google Maps told me the trip would take over 9 hours. I freaked out! We don’t have 9 hours, we have 30 minutes; is this the right address? Did we accidentally book an appointment at a venue 9 hours out of Ottawa?

Actually, it turns out I had Google Maps set to give walking directions. Again, my fault, but again, where were the developers on this one? Did they really think I wanted to walk over 9 hours to get somewhere? Why not recognize that I was probably looking for driving directions and put a message at the top of the screen asking if that’s what I meant?

(For the curious, this story did have a happy ending: we made it there a slight 15 minutes late, and this was the venue we eventually chose for our wedding.)

Exhibit C: Firefox’s Spell-Check

Firefox is an incredible piece of software. It is currently the browser of choice for about one quarter of all internet users, and in many ways helped to revolutionize the web browser market. But one area where it hasn’t really advanced as far as it could have is its built-in spell checker. I don’t have a fancy story for this one; the data speaks for itself. Here is a list of words that show up as spelling errors in Firefox 3.6:

Some of the internet’s most popular websites:

  • YouTube
  • Facebook
  • Myspace
  • Flickr

Well-known web technologies:

  • Skype
  • Silverlight
  • Webkit
  • WordPress, CMS
  • PHP, CSS (it gets HTML)

Very common computer words:

  • Inbox
  • USB

Extremely successful desktop software:

  • Photoshop
  • PowerPoint

Apple products:

  • iPod, iPhone, iPad
  • Macbook
  • iMac
  • OSX (it gets Linux and UNIX)

These are all very common words in internet parlance, and it’s ridiculous that they are highlighted as possible spelling errors. Why not add them to the dictionary? A simple white-list that could be crowd-sourced to the community seems right up Firefox’s alley; I wouldn’t be at all surprised to see this addressed in a future release.

What can we learn from this?

My main take-away here is that context is a big factor in software development, and one of the hardest to get right. Even the big guns have room for improvement, which means the rest of us likely do as well.

Categories
Web Technology

The Present and Future of Flash

Adobe Flash is at an interesting point in its existence. For about a decade, it was the only way to get rich, dynamic content onto the web. If it was the year 2001 and you wanted a really sleek UI, or video, or any kind of animation, Flash was your best bet — it was pretty much a monopoly. Then things started to change:

  • DHTML started to take over some of the really basic use-cases for dynamic events like rollovers and showing/hiding content.
  • AJAX made truly dynamic content easier for the non-flash world.
  • The mobile web started to take off, with most devices not capable of supporting Flash.
  • Microsoft released Silverlight, a competitor to Flash in the rich interface space.
  • Apple started releasing wildly popular devices that intentionally avoided supporting Flash.
  • Browsers started implementing support for HTML5 and CSS3, which are slowly being adopted by designs that would historically require Flash.

Slowly but surely, alternatives to Flash have been picking up speed, and things beyond Adobe’s control have prevented Flash from penetrating certain markets (mobile in particular). What does this mean for Flash as a technology?

Flash isn’t going away anytime soon…

This isn’t one of those posts about how HTML5 or the iPad or global warming is going to spell the end of Flash. Flash is a major player in many areas of the web, most of which won’t change anytime soon. In particular:

Games — There are tons of online Flash games. This is a huge market that Flash has absolutely dominated since day one, and none of the technologies mentioned above can compete with Flash on this level of interactivity.

Video — Like it or not, HTML5 is not yet strong enough to handle cross-browser, web-based video. Even when it is (and it will be sooner than you think) Flash will still be used well into the future because it’s the only solution for legacy browsers, and the vast majority of users don’t update their browsers as often as they should.

On top of that, Adobe has created an entire ecosystem of software and a vibrant community for designing, building, and publishing Flash-based applications. Plenty of people are heavily invested in these tools, and no amount of evangalism is going to convince them that their problems could be better solved by today’s Flash-alternative du jour.

…but Flash will start having a reduced role on the web in general.

It would be unrealistic to pretend that these new technologies aren’t eating into Flash’s market share. For one, even in the most complex cases, some projects are choosing Silverlight over Flash. Not the majority (not even close) but more than none, and Microsoft is a powerful competitor that can compete with Adobe on the development tools and community levels.

Secondly, HTML5 and CSS3 can do some pretty neat things. For cases such as modern, dynamic navigation and simple logo animation, it will soon make much more sense to use features supported by the browser than a heavyweight proprietary plug-in; especially if all you need is a quick piece of eye candy.

Finally, there are the problems caused by Apple. I can think of three:

No iPad/iPhone Support — The longer this keeps up (and I don’t see it changing anytime soon), the more likely it is that someone will create a cool, interesting way to do fancy, Flash-like things in an iFriendly format. And then a general-mobile format. And then a web format. The last thing Flash needs right now is for some brilliant start-up to shake things up even further.

Macbooks are getting popular — Adobe claims that Flash runs on every platform ever, but as Chris Rawson astutely points out in this excellent article, that’s been easy to say while most of the world has been running Windows. With Apple’s laptops gaining popularity, people are starting to realize that Flash doesn’t run as well in OSX. The more Macbooks Apple sells, the more Adobe’s claims of market domination will start to dissolve.

No iPad/iPhone Support: take two — I want this website to be viewable on the iPhone, the iPad, and whatever whimsical hardware Apple comes up with next. That alone means I’m not going to use Flash in my blog’s design, ever. I’m admittedly in a minority here, but I wouldn’t be surprised if today’s kids getting into web design are also going to want to show off their cool, new, standards-compliant sites on their cool, new, iApproved devices. This sort of trend will slowly but surely push Flash out of the cool-new-site space.

Getting along with OSX is something that Adobe is going to have to work towards to keep Flash competitive, especially as new markets evolve out Apple’s hardware.

I’m not anti-Flash.

I’ve been using Flex Builder to build cutting-edge Flash applications for years, and I still believe there are many cases where Flash is a legitimate choice for creating a rich internet experience; there just aren’t as many as there used to be, and this combination of new, exciting technologies and pressure from Apple are making for some exciting times in the world of web design.

2010 is shaping up to be a wild ride for Flash and its competitors, and I can’t wait to see where it takes us. What are your predictions?