So why is it that in this day and age we can’t seem to do a better job of using those lessons to streamline web pages?  One might say that it’s just novice approach – that in the rush to put out bigger and badder that we neglect to remember that not everyone has a 20Mb download speed.  To be sure, yes, there is the app conundrum – quite nicely championed by Apple (see this interesting reference) – which dictates that smaller is better.  However, I don’t think there would be much dispute that web pages have just gotten way too big.

So what defines big?  There could be a lot of parts to the puzzle.  First, of course, is just size (and I mean in bytes).  Too many unoptimized images, redundant scripts and styles, inline hacks, blah blah blah. When did schools stop teaching students to optimize? How many content producers bother to test the effect of changing the quality level in Photoshop before handing off images to inventory? These and many other questions perplex me every time I have to wait more than 10 seconds for a page to load on my broadband connection.

A more commonly overlooked problem is the number of connections.  I once asked my students if they understood the concept that the more the connections the longer it would take to get all the parts…or more succinctly, how much sewage can you pump through a pipe? Between both Art Institute and UNLV, maybe 1 in 50 had even considered the issue.  To illustrate the problem, open up Firebug’s network tab (or use Fiddler) and watch the network exchanges as the page loads.

To be sure, yes, we have a lot of bandwidth, but like any resource, it has its limits and like any resource, if we squander it, it becomes a precious commodity.  Back in the day, anything more than 6 connections on a page was considered bad form (and even consider that at one point, any cumulative page load of more than 65K was considered bad too).  I can’t even begin to count how many pages load in excess of 50 connections and over 2MB per page.

Fortunately, caching exists, and not because of something developer-designers themselves are doing, but because CDNs, server-makers and browser-makers all realize that the developer-designer world is basically inconsiderate and that they will not bother to tackle the problem they’ve created.

Many sites, to their benefit, are taking novel approaches to solving the problem.  First, there’s the stripped down interface – sites like Google, Twitter, and even Facebook to a degree all keep the content up front.

Now to be fair, there is a strain of developers (myself included) that are a bit anal-retentive about some things in the code realm. Take, for example, the question of using quotes to enclose attributes. HTML5 makes this an optional, but those of us old-timers who really watch coding practices generally prefer to leave them. But at what cost? Check out this article on JP’s blog. In it, he explains how @dom_monster tweeted about a page from GitHub that contained 4,517 quote characters and what effect that had on performance. Interesting question.

So at some point, preference will still take precedence. Where I work now, we are developing a new UI to help one segment of our user-base visualize big data, while providing tools to allow faster, more accurate, and more effective data mining in a web-based environment. And at the same time, the call to arms was (the very arbitrary) “make it cool.” Big task. Along the rapid pace of development, producing some 600 UX wireframes and composites, and digesting an entirely new methodology for managing syndication traffic sources, the interface bloated out to 1.8Mb (though fairly, it never has to reload since it uses trim Ajax exchanges and JSON objects to keep data intact).

Side note: Thankfully a little bit of re-engineering dropped that 25% to roughly 1.3Mb in the pre-alpha stage two weeks out from launch.

Anyway, my point is – we’ve become a culture either so strung out on putting new apps into the wild with all the UX bells and whistles, or coding so beautifully that it’s like watching a symphony unfold before your eyes reading the script, but less and less thoughtful about the end-delivery result to the user.

I live in NYC again, and frankly my AT&T connection sucks. Everywhere. And as mobile web consumption increases, so, seemingly, does the time it takes to get anything on the interface.  We hear lots of advertising about 4G and faster this and that, but it doesn’t give us (speaking to the designer-developer community) an open license to forget what it’s like to have less.  Just because we build an interface to work better on mobile doesn’t mean it’s truly DESIGNED for mobile.  UI and tactility and gesturing and all that buzz today doesn’t mean we’ve truly built a the (web) app to work better on mobile platforms because the other half of the equation is speed of delivery.

My point is – think about both sides of the equation. Consumers, your users, are becoming data hogs. As data needs increase, delivery inevitably slows down. Trimming your component delivery is a critical part of the design process, particularly in the mobile environment, but just as much so in the desktop world.

Just a thought.

Like many developer-designers, I do spend hours checking out the cool CSS implementations.  But an interesting tweet from Smashing Magazine got me to thinking about the idea of cool, the problem of trend, and some of the after effects of the rush to improve on CSS.

I grew into the Web before CSS really existed.  In 1994, I joined an inspired group of people with little technical knowledge on an endeavor called Visual Radio.  Over the course of the next four years, we carved out a pretty good niche in the market, largely due to a few very high profile projects (BizTravel being one) and some very profitable side projects (developing one of the first X.25 pad commerce gateways).  While the company later imploded, I learned a lot of good lessons in that time, not the least of which is that human emotion and responsiveness to a site or interface is driven by two very different needs – the need to be informed and the need to be pleased.

My end of the biz handled the “to be informed” part – that is, getting databased to appropriate the right information at the right time.  Yes, we are talking 1995 dynamic websites. While a subculture to be sure, it eventually led the way to most of what you see today, including the advent and prosperity of CMS, dynamic output, flexible and responsive design, and so forth.

My counterpart (the late Lucian Andrei) focused on making things pretty (remember kids, we were actually working in the web-safe zone at the time.  If you don’t know what that is, try living with 216 non-flexible colors).  In one very interesting example, Lucian created a texture akin to felt – something we take for granted nowadays but in its time on a website, very unique.  But I digress.

Lucian and I saw eye-to-eye on many things, but one thing we didn’t was the importance of visual design.  While I certainly understand the appeal of good visual design, for me, nothing less than perfect information delivery was more critical.  For Lucian, the information delivery could only occur when the visual appeal was met.  Which leads us back to CSS.

Imagine, those of you borne into the Web post (say) 2002, that you had NO ability to perform transformations, render curvy corners, or use anything other than one of the seven web-safe fonts.  How would your designs look? Sure you could slice up images, but then also remember that a web page over 100K was pretty much non-existent.  And no, we didn’t get Ajax until just around the turn of the millenium (really not until 2003 when Gmail really showed us how to use it).

What would your design look like then?  Would you suddenly need to shift your focus on the information?  There are many of us (yes, you call us old people, senior citizens, etc, but I prefer to think of us as Yodas – wise and with a lot of kung fu that might kick the crap out of you) who will argue that if you can’t deliver the information properly without all the glitz then you aren’t really delivering anything at all but a lot of paint.  We remember a time when the only thing we searched for was a lot of text.  And we almost always found what we wanted (assuming it even existed).

Now I am not diminishing the value of visual design.  As a developer-become-information-architect, half of my job is to insure properly information and knowledge transfer with the best visual representation possible.  I spend hours every day just thinking about how to graph a 10,000 row, 20 column spreadsheet into a nice, neat chart.  I spend weeks thinking about the implication of using an unordered list instead of a combo-box, and whether the development time is worth the cost.  Visual representation is how we do things in this day of the Web (20 years later) but it still doesn’t beat simple data delivery.

On a broad spectrum, I might even argue that CSS has made us stupid.  OK, maybe not stupid, but less inclined to bother.  What I mean is that, because our eyes (and even hearts) look for the pretty, and as we have more and more information shoved down our throats, can that quantification be because of extra crap that we don’t need being thrown into the mix? Do we need to feel good about data or do we just need to slam it down and begin making conjecture about it? Can we search without having a location-based map, 20 advertisements, ratings, and all the other junk thrown on top of decisions we are already trying to make?  I love the diversity of today’s Web but I reminisce that some of the important parts of the past are getting lost with the new breed of developers.

So before you start running amok with the CSS, think about what it is to deliver the information without it.  Could you do it?  Would you do it?  If you wouldn’t in the first place, it might not be data worth delivering at all.  Think before you do, that’s all.

“Software is a gas,” he said. “It expands to fill its container.” In fact, that is more of a policy than a necessity. “After all,” he observed later with a laugh, “if we hadn’t brought your processor to its knees, why else would you get a new one?”

Reiger mentions ’Myhrvold also goes on to say that: “In demos, the new technologies are inarguablycool. Cool is a powerful reason to spend money.” Fifteen years later (the article is dated July 1997), little of this appears to have changed. Make of that what you will.’

Thoughts? Has the Web influenced this, or are web applications becoming so heavy that they aren’t any different than apps of the past, just using bandwidth AND processor in tandem?  The application in progress here loads 1.4MB one time then caches the rest but does regular data exchanges that range from 10K to over 1MB. It’s not super efficient but it is balanced as much as it can be considering that it is a Big Data application.  How do we define things like efficiency, bloat, over-featured, over-designed in an age when we have the power and the game is to keep right along the (bleeding) edge without falling over?

I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.

Every year there were always some pretty good ideas fleshed out, but basically the sci-fi-like concept was that there would be a device that, via bots, utilized data from multiple sources, aggregated them, and devised some kind of intelligent guess to guide one through life.  I’d give the example of a device that reminded you that you needed milk because it looked inside your fridge but told you to go to a different store than usual because the route to your normal market had too much traffic due to an accident and the corner deli’s milk was expired (etc, etc).

Given the very fast moving mobile capabilities, Google’s new Project Glass may be just that thing and maybe just one step farther. Though it may be quite a few years off, I’d debate even that.  Gone are the quirky augmented reality components, replaced with iconic “touch” apps – that’s the first good step towards a really usable design.  The second is platforming it with things we already do with our mobile devices.

In any case, the video is well done and pretty suggestive and this is something I’ve been waiting for.

Google’s Project Glass

Lots of changes – new job, new place, new perspective.  The new gig is in full swing – working on the design of a very kick-ass web interface for search syndication ad management. When one’s impression of internet advertising is what you see in AdSense and DART, it can become very skewed, as well as undeveloped.  The world of search syndication is huge and amassing like a snowball rolling downhill.  Even here we’re just beginning to realize the potential of some untapped areas and trying to develop an easy-to-use interface to both educate and improve yield for the customers, while simply trying to get our own arms around it at the same time.  More on that actual development another day.

Anyway, just dropping my hat back into the ring. This will be an interesting, albeit exhausting, quarter.

The Things I Will Miss

• The unfettered creativity of students whose minds have not been destroyed by the realities of life
• Intelligent questions that even make me think
• Students who bother to challenge my opinion (or even better, a methodology)
• The thanks from the one student each semester who tells me that something they learned helped them get their first job or changed their mind about [insert topic here]

Things I Won’t Miss

• Students who think I don’t know that they’re on Facebook (and those of you in INF400, yea, we did hack your passwords)
• Blank stares, the head nods (despite being good for comedy relief)
• Fluff.  (Please, if you’re a student and reading this, a quick word of advice – answer succinctly or just admit you don’t know)
• Superficial essays. (See above – do your [expletive] research – there is such a thing as a library)
• Lack of effort, especially on exams (I mean, please, if you ASK me for true-false and multiple-choice, then you should get at least better than 50% correct, and even more so when I tell you how many question on each topic and mark my slide sets with the important slides)

Anyway, I say maybe because there’s still a chance I might be returning for INF400 Web Security but not likely.  So to those students who at least appeared eager that I would be back for one more round before UNLV shuts the doors on Informatics forever, I’m sorry I didn’t tell you but keep at it and don’t be afraid to email me if you have questions.

First, interestingly, the article specifically asks for comments, yet (even when signed in) readers are never presented with a comment box.  Frankly, I’dve just posted my comments there but now I feel compelled to write here.

Second, relative to the article itself … of all the sites presented, they all stink. The problem with Flight Status checkers is that fundamentally they all use similar methods, similar input tools, to acquire the data.  What this means is that you get a screen with several selectors and several free-type inputs.  Despite advances in the UI tools for both selectors and typing, they are still fundamentally difficult to use, particularly for situations that many users find themselves in when using these services (in my own case, I found myself driving in 6 inches of unexpected snow in NYC this October and trying to get a JetBlue status).

One of the nicest things about having been in the industry for so long is that I can reminisce and consider technologies that we don’t often see today but that may still have applicability.  In this case I am referring to the “deck” principles used in HDML in early versions of phone browsers.  The deck principle basically provided that multiple pages of data were transferred with each page call, reducing the number of times callbacks were required and increasing the individual interactivity by allowing data to be shuffled between “cards.” Couple that with good Ajax utilization, and you might have a pretty neat app.

For a good flight status checker to work, think in terms of the actual UI.  In my own incident, I needed to not have to enter keyed data – just click and fire with easy-to-hit buttons and less on-screen information.  What I propose is something more like this (and I apologize, I sketched this out real quick just now and sent it with my phone cam).

Here you get no more than a couple of selections per screen, always presented as click buttons.  The beauty is that you can use Ajax effectively to pre-load all of the subsequent screens with minimal data transfer.  For example, by coupling the Location Services data of the current location along with the user selections, you’d likely be able to guess the probable dates and flight numbers (no more than 3 days future, any given airport, within a 6 hour time window, the lookup is no more than about 40 flights).

Another problem I faced was that all of the interactions used POST, which means that it was impossible to go backward and still have the data intact (so I could modify one small bit and try again), forcing me to re-enter 6 fields of data each try.  Using the hashtag approach, you’d also allow for backward and forward runs through the history.

Thinking through the user experience is part visualization, part interaction, and part data process and information architecture.  Trying to remove any part of the puzzle leaves something to be desired in the final product.  Flight status checkers are a great utilization of mobile web, but THINK the process, use it, determine what can be made better, and do it.

The article…

The Design and Display of Simple Interactions on Mobile Devices

By Shanshan Ma [November 21, 2011] on UXmatters.com

Users visit mobile sites not only to consume content, but to get things done. Let’s take air travel as an example: tasks that users often find themselves performing on an airline company’s mobile site include checking flight status, checking in for a particular flight, and searching for and booking a flight. How does mobile user interface design support task completion? What are the optimal ways of communicating and displaying interactions on mobile sites? With the aim of discovering optimal ways of designing simple interactions on mobile devices, I examined the task of checking flight status. I’m hoping that my analysis sheds some light on this topic.

The Interaction: Checking Flight Status

Travelers can initiate a status check for a flight by locating the flight using its departure date, plus either the flight number or the departure and arrival city or airport for the flight. Sounds simple enough, right? Analyzing this task, here are the steps that are involved in checking flight status:

• Step 1—Decide whether to check flight status using a flight number ordeparture or arrival cities.
• Step 2—If using a flight number, type the flight number; if the departure city and arrival city, type the names of the departure and arrival cities or their airport codes.
• Step 3—Type a flight date.
• Step 4—Submit the form.

It’s fairly easy to support this task on the Web. Simply present both options on a Web page, and users can proceed according to the information they have about the flight—whether flight number ordeparture and arrival cities. While it’s easier to type a flight number than city names or airport codes, users tend to remember flight cities better than airport codes or flight numbers. However, there are a few interesting details that you should consider:

• Which question should you ask first: flight date or flight number or flight cities?
• Which option should you present first: flight number or flight cities?
• Should you ask for the flight date twice to ensure a complete workflow regardless of whether a user is checking the status of a flight by flight number or flight cities or airport codes?

Here’s a post on MSDN by Rob Mauceri with more details…

I’ll let you check out the rather extensive method and event list, but be assured that the things we really like about jQuery – the $(selector), the quick data methods, and several events for data handling – are all there.  Plus there’s several plugins to tack on more methods and events without the total KB package jQuery sits on right now.

On the flip side, if we could just get everyone to DL the .js from the same source URL (such as //ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js) and reinforce caching, we wouldn’t have as much problem anyway.

Mobile is a platform. It is a tactic, not a strategy. What you need is a strategy for the connected customer.

If a Norwegian man is sitting on the toilet reading the news on his iPhone, is he mobile? Well, research indicates that one of the most favored places where Norwegian men use their phones is on the toilet. iPads are used a lot on the couch but the iPhone is more popular in bed.

Mobile is not necessarily mobile. It is flexible, convenient, fast, and private. Pictures of sexually transmitted diseases are often accessed through mobile devices. This could be because mobile is particularly favored by young people. It could also be because a phone is more private than a computer. A number of people might have access to the computer you use, for example.

I’ve read that mobiles will be used a lot this Christmas, particularly for last minute gifts. That implies that people using them may need advice on what to buy, because by definition they will not be buying for themselves.

“Desktop copywriting must be concise. Mobile copywriting must be even more concise,” Jakob Nielsen writes in his article ‘Mobile UX Sharpens Usability Guidelines.’ We need more than content reeducation according to Jakob. “The feature set should be much smaller for a mobile site than for a desktop site.”

However, the customer is not always in a hurry. Some people read more on their smart phones than they read on websites. So, one of the most important links any mobile website can have is a link back to the main website.

A major weakness of organizations is that they behave reactively rather than strategically. “We need a mobile app.” “We need to be on Twitter.” “We need more video.” “We need to blog.”

Web strategy is far more about psychology than technology, blogs, Twitter or any other forms of content. The more people use the Web to live their lives and do their jobs, the more web professionals need to invest in understanding human behavior. This is because the Web removes the human touch points, the opportunities to observe, the empathy zones.

There is so much we learn when we are physically in the presence of our customers. If I were hiring a web professional the greatest attribute I would look for is empathy; the ability and desire to put yourself in someone else’s shoes. A web professional should have a service heart.

What are Norwegian men doing with their smart phones when they are on the toilet? What do people typically do when they are on the couch? Do the tasks change when they get into bed?

Read the original article and other good stuff from GM here.

My thoughts are that this is more or less semantics. GM is right and wrong.  Mobile is a platform. And it’s also a strategy. They go hand in hand, but it depends on the target audience and their needs.  A good example is YouVersion‘s Bible app (available on pretty much every platform under the sun).  I’ve been using the app from several updates back (about 18 months now) and it’s gotten progressively better and better, not only from a content standpoint but also in it’s delivery. Note that the content isn’t copywriting in this case – the Bible is the Bible (at least in whatever version(s) one likes to read).

The feature set, however, is pretty much the same on both the desktop and phone/device systems. What differentiates the app is the delivery – well designed and heuristically easy to figure out.  And for the most part, I’m not in a hurry when I use it.

Fast forward to this week when I offered to help my church fix their suffering web site (which I will be writing about over the next few weeks).  One proposal is to improve the mobile presence, and yes, it is part strategy and part platform simply because what we use each for will differ.  The web site one would use for basic information, which the mobile would largely be for contemporaneous and updated event information and social connectivity.  Two different needs, significantly different physical presence limitation and likely different user groups.  So sometimes we do have to look at the device as a platform and not just a strategy, but without the strategy there’s no point to the platform either.

And just a note, as of this writing, this blog has no (good) mobile presence or strategy.  I’ll get to it one of these days.  When my wife asked why I don’t hold off (re-)launching until I had it all in place, my response was “why wait?”  Is there a point to holding off?  If I had 10K visitors a day like she does, I could see it, but the small handful of people who might actually read this are highly unlikely to do it on your iPhone (or Android) so I’m pretty much not worried.