Yesterday evening, I met with my husband and a fellow designer friend at Dundrum Town Centre for a meal (Singapore Noodles, if you’re that curious) and a film (Captain America). At some point, conversation turned to my latest project – an interactive information touchscreen kiosk for another shopping centre, in a different part of town. Right now I’m working on the design, and my challenge lies with the size and orientation of the screen: respectively, Huge and Portrait.
Over dinner, we had a discussion about how different parts of the screen would be more accessible for tall vs short people. Afterwards, we had a stroll through the centre to kill time before the film, and stopped in front of one of the many non-interactive advertisement slideshow screens stationed around the ground floor. While slightly different in size and shape from my target screen in that other centre, they were similar enough to stop and see which area would be our “sweet spot” for interacting with this type of screen.
This is where all our UX -pectations went down the drain.
I pointed somewhere just above eye level. Both my husband and friend pointed downwards towards waist level.
We all hit the SAME spot.
I’m a girl, and quite short for one. They’re both blokes and above average in height. I expected their “sweet spot” to be way above mine. So what happened?
My guess is, that as a short person, I’m more used to looking up all the time at all those improbably walking trees (yes, I’m talking to you, Treebeard!). Conversely, my Big Friendly Giants are used to looking down at Hobbits such as myself. And so – against all expectations – we all ended looking at and reaching towards the same area on the screen.
Now over to you. Is your User Experience with other-sized people and objects similar or completely different again? Let me know in the comments.
A Website Owner’s Mobile Strategy Guide – Understanding Responsive Web Design and Mobile First Approach
Once upon a time in the kingdom of Interwebs, a website only had to worry about one thing: how to look good on a high-resolution screen. Certainly, content was king even in those days. But it fell to the queen to entertain the guests, and all visitors entered the castle through the great gateway of a desktop or laptop monitor. Except for those poor buggers on mobile WAP, but they had to use the back door anyway.
Fairy tales aside, it is the restless nature of technology to be ever changing. This evolution is driven by social change, incited, in turn, by technical progress. From Ogham stones to telegraph to smartphones. Perhaps in the future we’ll all be browsing the internet with our neural implants.
In the meantime, back in the present, the messages are blitzed into our eyes from a bewildering variety of media with different viewports and resolutions. Web browsers now occupy Smart TVs that barely fit in your living room as well as mobile devices that fit in the palm your hand. If your website cannot adapt, mobile visitors may get tired of pinching the screen with their fingers and surf away.
My inbox is full of newsletters from Adobe. Creative Suite 6 packages are shipping, Creative Cloud has arrived, and the Messiah is riding to town on his donkey … All this could be yours if your tech-fund hasn’t been depleted by, say, a recent forced upgrade to 5.5.
One of the new features in Flash 6 is the HTML5 converter. If you’re a Flash developer, you might be feeling a certain amount of chill aimed at your hard-earned expertise. With HTML5 the coolest kid on the block, we are no longer the apple of our step-parent Adobe’s eye. Don’t get me wrong, there are still great uses for Flash, which leverage its awesomeness in ways the new kid can only dream about (shameless plugs: Yeats and TimeTwister). But for everyday web design, we must make like the Borg and adapt. One way is to leverage our Flash know-how for HTML5 development.
If you’ve upgraded and used the converter, feel free to leave a comment about your experience. On the other hand, you may have your own reasons not to upgrade just yet. Guess we’ll have to wait to convert our Flash animations … or do we? Google Swiffy to the rescue!
Well, mostly. You won’t be able to export an entire website, a sophisticated game or RIA application, or anything that relies on ActionScript 3. This knight in shining armour is less Sir Lancelot of the Round Table and more of an Alice in Wonderland White Knight.
So what can you do with it? Swiffy Gallery has examples of converted animations and even simple games. I used the tool to convert my animated logo at the top of the page, and the iframe below holds a Swiffied example of my old logo animation (or click on the Swiffy Tree link here for an unmodified source file):
In the past year or so, when I mentioned or thought about the Neo-Archaic website, I often found myself quoting an old proverb: “The cobbler goes barefoot.”
It’s a great excuse to have. Too busy to redesign my own website. How can I even think about wasting so much time? Oh my paws and my whiskers, nearly late for that deadline!
For most businesses, the decision to redesign a website boils down to two questions:
- Can I afford it?
- Can I afford not to?
Even if you already have a web-presence, there is still the need to keep up with the breathtaking acceleration of Internet technologies and social change. Only a few years ago, who ever heard of Facebook or Twitter? Appearance is another deciding factor. Is a “past-best-before” design giving indigestion to your public image? What about engaging your visitors with fresh content? With WordPress, or a similar CMS, you could update and post new content on the go. And speaking of that – do you have a mobile strategy?
So you make your decision and start shopping around for a web professional. Or for an actual pair of new shoes, if that’s what you’re after.
But when it’s your job to redesign your website, it gets more complicated: it’s all about time. Too easy to put everything off until that project is finished, and the next one. Thus the cobbler goes barefoot and ignores the thorns in her foot and the broken glass and the –
At some stage, you simply can’t walk any further without that new website … I mean shoes.
And so, I am pleased to present to you the new Neo-Archaic website: now with more neo than archaic.
At last, I got around to porting my Tooltip Class to Actionscript 3. Well, when I say “porting”, that’s not quite accurate: this is a complete rewrite. As such, alot of property names in the options have been changed, some of the defaults are different, and there are a few more public methods. So if you’ve been using the old AS2 Tooltip, don’t just copy and paste your code, first have a look at the Class, which is fully documented.
Download the Tooltip class
If you’re not familiar with the old AS2 Tooltip: this is a customizable static Singleton Class for generating and displaying Tooltips from anywhere in your code. There are no assests for the library, since the tooltip is created and drawn dynamically, by invoking the static methods:
Tooltip.show(tooltip:String = “”, localOptions:Object = null, target:DisplayObject = null)
But now there’s another way to invoke the Tooltip: DisplayObject instances can now subscribe and unsubscribe themselves from the tooltip for automatic handling:
Tooltip.subscribe(target:DisplayObject, tooltip:String = “”, options:Object = null)
A couple of days ago, having just installed a new version of the Flash player in Internet Explorer, I tested recent updates to an ongoing Flash project. Imagine my amazement when, instead of an interactive Flash exhibition, I got a notice that my Flash version was not up to date. Thinking that maybe something went wrong with the recent installation, I went to the Adobe website and reinstalled. Still, no luck.
ObjectSwap has a nifty param line for version checking, and in this project it looks like this:
<param name="flashVersion" value="8" />
The current flash version in my browser is: 9,0,115,0, and up until now, the version checking code worked in such a way that if the version declared in the param is lower than or equal to the installed version, the Flash content will be displayed, and otherwise you get the alternate content – in this case, a request to download the latest player. After playing around with it, I saw that either I had to change the version to 9 in the param, or remove it altogether. In other words, all of a sudden, IE requires the exact flash version of the player, rather than the version of the movie. Madness…
I love my Tooltip, I really do. There isn’t a project where I haven’t used, abused and made it do unspeakable deeds. In fact, I’m surprised it hasn’t filed a lawsuit against me, for unpaid overtime. But I’ll be the first to admit that the original version was just a little bit flawed.
Ok, maybe not the first to admit it – quite a few of you noticed the strange wrapping bug when used with short strings, and I recieved many requests to have it move with the mouse, fade-in and out, and even support custom shapes.
Well, now it does all that, and more…
The need for a tree-view arose when I was adding a FAQ page to the Pediatric Center website. I didn’t want a long scrolling page, and it appeared to be a tedious affair to create all those internal links and anchors. A treeview structure seemed ideal for a FAQ, but then I couldn’t find anything usable on google (At this point you might say that my google skills could do with some polishing, and come up with a list of wonderful scripts that I completely overlooked…), and besides, good clean dynamic xhtml is still not that easy to come by.
If you are a web designer who tries to combine high standard graphic design with top-notch web-standards xhtml, you can’t escape a certain degree of conflict of interests. This can be especially acute when it comes to designing a menu. You want it to have a strong graphic look, elegant and glossy, and yet you’d rather use a semantic xhtml list with text links.
Your life might get somewhat easier when it comes to headings, with various CSS Image Replacement techniques. But they’re not perfect either, and for menus you need be able to hyperlink the image.
So what can you do?
- Use CSS to format your textual menu to it’s best abilities, using the same old fonts and maybe a background image to make it look nicer. Don’t even think about using an interesting font like Arcitectura, or adding some layer effects in PhotoShop, because then you’ll have to use images.
- Design a Flash navigation bar, which is again not very semantic, SO friendly, or accessible. I’ve nothing against Flash, in fact, I I’m a huge fan. It can be used to great effect to add an extra dimension to the website with animation and interactivity. But just like salt and pepper, you need to know when to stop adding it. Graphics or drop down menus are not a good enough reason for a Flash menu – these can always be accomplished by dhtml. A Flash navigation needs to be exceptional (or at least quite interesting) to justify itself, and even then you’ll need to add textual navigation somewhere on the page, at least for the search engines.
Most of my xhtml websites up to date have been achieved with the first method. Take a look at my own website, for example – it uses CSS and background images for formatting, and the font defaults to a generic serif. Even then, it took a lot of work and a bit of extra markup to achieve the look.
My latest website project (not yet published as this goes to “print”, but soon to come) is for a glossy fashion wholesaler, and that meant top-notch graphics, even for the menu. For this I came up with option #4 – NavSwap, which happens to be the object of this article. It took some code wrangling to write, but is quite easy to implement.
You can download the script and examples here…
NavSwap serves two functions:
- Automatically swaps images on rollovers and swaps the current menu item with an active state item on each page.