blog

hello, I'm Craig Morey. No, not that Craig Morey.

[atomoco-blog]

Earlier this year we spent a week in a relative's farm house in Southern Sweden, and found some gadgets that I remember from my own grandfather's house. During this time of dredging up and re-interpreting old user interfaces (in skeuomorphic or interpreted form), I thought I'd catalogue a few of them.

The light switch.

I know. A light switch is a light switch. Except that they're not. In the UK, the default is a pretty dull and nasty small and stiff rocker switch that is just larger than two finger tips. Here in Sweden, the modern alternative is a nicer and much larger rocker pad, that is an easier hit target and feels lighter to the touch, probably just because you don't hit it so close to the pivot.

But at the farmhouse, the light switches are the the old style rockers. And they're lovely. 

There's a lightness to the spring that makes flicking them a joy. You barely touch them for an immediate effect. And because you flick them with an outstretched finger, theres no stabbing and stubbing, no unsatisfying "smudge" as your digit slides off the switch. Even the click sound is delicate.

If the hit target is small - for instance in the dark - reach around the side of almost any door and swipe down with the whole of your hand. Much easier.

I'm not sure if manufacturing cost or simply a change in style made this design die out. In your typical stripped-down mid-century house maybe they suddenly looked a bit "fiddly", a bit "Victorian". But the tactile action and user friendliness still betters the UK light switch. Maybe it's the button we most press during our lives, maybe it needs to be re-evaluated.

[atomoco-blog]

LTE and the UK

Sure I want LTE. Yes, I'd like an iPhone (at the moment). I know that only EE currently have LTE in the UK and the rest of the pack will join the party around May next year (2013). 

The way I see it, I want good coverage and good penetration - I live in a block of flats in North London that acts like a faraday cage. Getting WiFi to reach 10m is hard enough, while cellphone coverage is pretty much non-existent across all networks.

So I wondered is all LTE created equal?

The general consensus is that the lower the frequency, the better the coverage and penetration. With WiFi, running on the more normal 2.4GHz reaches through more walls than the alternate 5GHz (noise aside). I'm also aware that my current iPhone runs on O2 3G at 2.1GHz. Both of these are crappy at home.

So the lower the LTE frequency the better, sub 1GHz would be great. Currently in the UK we have EE running on the 1.8GHz band, Three will use the same when it launches, while O2 and Vodaphone will be getting either the 800MHz or 2.6GHz bands next year (both widely used in Europe).

Which means whoever gets the 800MHz band gets my account, right? Well, it could depend on what hardware is available.

Around the world, there are about 9 different LTE bands in use - an inevitable consequence of trying to find clear spectrum globally. The device manufacturers understandably don't want to support every possibility in every phone, and instead pick common subsets.

For instance the "rest-of-world" SKU of the iPhone5 supports 850MHz, 1.8GHz and 2.1GHz, which gives it pretty wide support around the world, including EE in the UK. But it means no LTE for iPhone5 on the Vodaphone or O2 - unless Apple release an additional SKU in the future.

It's clear that a "tiny" phone (for LTE) like the iPhone 5 only has space for a limited amount of aerials, whereas the much larger Nokia 920 can more easily support aerials for 800MHz/900MHz/1.8GHz/2.1GHz/2.6GHz. Samsung take a different route, instead making ten different SKUs, each for a different market, making it less a "world phone", but much easier to sell widely within a country.

It's a jungle of a market that's incredibly young, so there's no clear solution for the manufacturers that gives global coverage, manufacturing efficiency and compact device size.

To sum up, if you're interested in LTE in the UK but don't want to jump in with EE, there's no point in thinking too definitively just yet. When the UK 4G market really gets started next year, I'll be eagerly looking at who gets which band, whilst keeping an eye out for what devices/OS are on offer at that point. At this market pace that could mean iOS7, WP9 and Android Victoria Sponge (kidding).

But in the meantime there's nothing wrong with a bit of research ;-)

[atomoco-blog]

Weird CSS part 14 million and one. This table has a cell with a simple CSS gradient and a dashed/dotted border on the opposite side. The trouble is, the border appears solid, not dashed - for no apparent reason.

Once the border is changed to red, you can see whats happening. The border sits on top of a  shadow-dom grey border, a mirror of the left side of the cell with it's gradient. This happens in Chrome 20/FF14/Safari6, so it must be expected behaviour, unless you're a human I guess.

So the fix is clunky, add a one pixel change to the gradient on the opposite side and it's all back to normal (apart from that nasty one pixel jag where the cell joins the heading - dagnabit)

[atomoco-blog]

The three horsemen of creativity

When it comes to creativity, I have three basic states of mind, and each one is both constructive and destructive. Each one takes hold of me at a whim, when I would rather be more in control of mixing them up. They both fuel who I am and they hold me back from what I could achieve.

Researcher.

Even before the internet - yes, I'll admit there was such a time - I was probably the archetypal info-freako. If I was interested in a subject, there wasn't a library, magazine or documentary that I didn't shake all the specfics out of. 

It's easy to see your stamina for info-consumption as a strength, after all, you can't point to a great writer who wasn't an avid reader. And you may become the go-to person to ask a question. But gluttony for consuming information leaves no time to create your own works.

And things are so much worse now. Even with concious strategies for triaging information like skimming hundreds of RSS feeds and sending a precious few to instapaper in endless micro-moments only helps taste the spray of the sea of todays information world.

I could have a full-time job gorging myself with new information. To no end whatsoever, feeling comforted that I'm learning new ideas, but not producing a single idea of my own.

Doer.

Real artists may steal, but they also have the taste and skill to make something appear new. The rest of us can follow a style and make something that looks at best "clean" or "professional". That makes us the doers, trusty sidekicks to the designers of the world.

Experience has taught me that too many design egos in a room has a negative effect instead of a positive one. You need people to be able to actively question the creative thought, but in the end to get on with the donkey work of "getting shit done".

I actually love this part of the job - the sitting down and working through a problem, followed by the endless polishing so that it's done right, damn it. It's a pride thing. It's the Malcom Gladwell part of a job - the nervous trial and error that gradually hardens into a nugget of experienced certainty that you can then throw at a new job, and appear the prefessional that you are.

Empires were made of that sort of work. But it's also the comfortable path, the following of others that never breaks the skin of a new idea. Endless pats on the head only encourage you to build similar work, Pavlovian style, before you tire and want to bite back on the patronising hand. 

It's the thing that makes time pass so quickly until you notice you missed your chance to make a dent on whatever world you work in.

Creator.

Sitting down and coming up with an idea. There's a noble pursuit. It doesn't have to solve cancer, kill poverty or generate clean energy - a neat little website to re-organise how a team allocates design jobs would make me happy.

But it comes with it's own problems. Getting the time inbetween the "research" and the "doing" to really think is hard enough. Having the clarity, the focus and the perspective to sift the sludge and visualise the good stuff is another snag. But then crystalizing a thought into a plan and bloody well executing and completing that plan - that's where the true genius of creation lies.

You can come up against technical limitations (so often your own), but more often a lack of time, energy and passion to follow it through. The wasteland of half-finished good ideas is a heavy net that drags me down. Every new unfulfilled idea is left behind like a dropped penny you can't be bothered to pick up, so you casually make out that you didn't notice you dropped it at all.

And the next idea that comes along is a little harder to act on, because despite your bluster, you can't hide your own track record from yourself.

The three horseman of creativity.

These three phases of my mind wrestle with each other. All of them are essential, but only in the right proportion will they achieve anything outside of the ordinary. Most of the time they just get in each other's way.

I've yet to prove to myself that I can mix them well enough to successfully lead rather than follow. To build things that make people want to work with you, instead of want you on their team. To inspire instead of please.

I sometimes call myself lazy. By that I mean that I spend too much time on the research and the doing - because they're comfortable and necessary. And they happily take up the time that would otherwise be spent on taking a risk on a new idea - then following it through to it's conclusion, for better or worse.

Funny thing becoming a dad. I'm more aware of risk, but I'm more aware of the ways it can really pay off. 

So here's to more risk, and the right mix of creation, work and research that could make it pay off.

[atomoco-blog]

Installing SSL email certificates in iOS5

Working on a new project meant that I needed to start using signed and encrypted email for communication. I'm not much of a security geek, so all the terms and conventions were a bit confusing, so here's what worked for me.

I eventually downloaded a free email certificate from InstantSSL.com (as Comodo.com's email cert page was just a 404…), and it installed into Apple Mail on the Mac with little fuss. Lovely. The only problem was that now I couldn't read the emails on my iPhone/iPad, or send signed/encrypted ones. The good news is that I was running iOS5 beta - which can use email certificates. Hurrah! Now if I only knew how to get it working.

My email certificate was a ".p7s" file. Getting it onto the iPhone (by email or dropbox) was no use, the iPhone didn't know what to do with it.

Eventually, after much googling, it appeared I needed a ".p12" file. You get one of those by using the "Keychain access" app in "Utilities" on your Mac. You import the certificate into the keychain, then click on your new certificate and export it as a "Personal Information Exchange" (P12) file. You can choose to add a password to this file, which means you don't need to add a password when you get to installing it on your iPhone, but I left it blank.  

Google was telling me that other intrepid iOS5'ers found they needed to then also export the same thing as a ".cer" certificate, as both were needed. I can't tell if that's true, because I followed their advice blindly.

Now you need to get your two new certificate files onto your iPhone. You can download the mysterious "iPhone configuration utility" app to install the certificate, but it didn't work for me. I settled for the tried and tested "email them to yourself" - probably making security experts wince, but hey.

I clicked on the two attachments and they installed into iOS with no problem. Then the email was deleted, and checked it wasn't in trash for good measure.

You're not done yet, you need to set up iOS mail app to sign and encrypt outgoing email. You have to go to the "settings" app on your iPhone, and right into the "advanced" details of your email account. Set the "S/MIME" switch on for the account your certificate is for, and set the "sign" and "encrypt" settings to yes (each one makes you select the email certificate you've just installed).

Lastly, I backed up my email certificate somewhere safe, in a passworded DMG file. Yes, in more than one place.

Congratulations, you can now send and receive signed and encrypted email. Happy private conversations.

More help:

Using S/MIME on iOS5 beta

Sending and receiving S/MIME encrypted email on iOS5 beta

[atomoco-blog]

Apple history is my history

On this day, I realise that Apple has helped get me to this point in my life. Thanks Steve.

[atomoco-blog]

That was fun. I've built a little favelet today, a browser short-cut to help with developing web-apps that have elements sliding on and off the page.

It's called "Honey I shrunk the page" (or HISTP for short), and it applies a CSS transform on the document body, so that it all shrinks in the browser window. The website works as normal, at the same aspect ratio of your window, just shrunken down so that you can see what's happening off-screen.

To use it yourself, drag this link --> histp <-- to your bookmark bar. Then click it to run it, and click it again to cancel it. There are a few options to let you customise the experience, just hover over the input boxes to get an explanation. The source is hosted on GitHub. I'll sort out a proper "product" page sometime in the near future.

Enjoy!

[atomoco-blog]

GPU memory management with hardware accelerated CSS transitions.

See that? That's the difference that GPU hardware acceleration of CSS transitions can make on an iOS device. If you don't know what CSS transitions are, you might want to stop reading now.

For those that are left, I won't bore you with how CSS transitions can provide basic animations, or how they can be GPU hardware accelerated on iOS devices, which can make an incredibly low-powered platform like an iPad offer smoother animation than big desktops running javascript.

Instead I'll run through how Bardot currently does the "next page" trick, and how I'm trying to improve it.

As a caveat, I'm just imparting what I've learnt through trial, error and Google - I wouldn't count myself as an expert on this.

Bardot is built in "pages" and "spreads". Pages are... er, pretty self explanatory, and spreads are the equivalent of opening a magazine spread (ie two or more pages facing each other). Bardot actually has three piles of spreads *, at any one time you see only one spread on-screen - in the "viewport". Either side of the viewport are two other piles, and when you hit the "next page" button, the piles all shuffle along one direction or the other.

The mechanism for doing this on most modern browsers is simplicity itself. Spreads in each pile have a particular class (".read", ".active", ".unread") and to move them around means changing their class via javascript, CSS transitions and transforms do the rest for you. As an aside, that makes quick changes to the animation a doddle (Make it quicker? Tweak the CSS style. Add a 3D flip out movement? Tweak the CSS style).

That all looks fine on desktop browsers, but iOS devices need a bit more help. They've got pretty limited processing power, and extremely limited memory, which often ends up with low frame-rates, sudden disappearances, or giving the "tiling" effect you see in the video above. This is especially true when you're creating something off-screen, then moving it into view (like we are here), because mobile devices are optimised to only deal with on-screen pixels to keep them lean and mean.

To get around that, we can hand off the "compositing" of certain elements to the 3D GPU chip in the iPad or iPhone, which is way more adept at flinging tiles around a screen. You can move an element to the GPU by adding a 3D CSS style to an object (some use "-webkit-transform:translateZ(0)", others use "-webkit-transform:scale3d(1)")

In the case of Bardot, I created a style class called ".zippy" with a transform of "translateZ(0)". When a page-forward event occurs, the top of the ".unread" pile is changed to a class of ".active.zippy", and the retreating spread is given a class of ".read.zippy". So ".read" and ".active" are the classes that determine where the spreads move to, and ".zippy" is the class that adds a sprinkling of acceleration.

The question begs: "So why don't we hand everything off to the GPU with 3D CSS?". Well, the GPU is also really limited in the amount of memory it can handle, and the more you stuff into it, the more it stutters and you're back to where you started. In Bardot, one of those spreads could be thousands of pixels in size, it doesn't take many of those to really bung up a GPU.

The trick is memory management. In Bardot, only the ".zippy" spreads are hardware accelerated, and once a spread is moved off-page, the ".zippy" class is removed to reduce the load on the GPU.

The result is buttery smooth animations in both directions. Simples.

* Note:  I've tried building systems with a long continuous "conveyor belt" of pages in the past, and although the theory behind that is cleaner (moving a huge track of pages past the viewport), I find working in three piles is easier to manage, especially when you get into dealing with layouts that are many spreads long. A track would becomes tens thousands of pixels wide and you have to deal with big margin offset numbers. Not pretty.

[atomoco-blog]

Philosophy vs Speed.

The original idea behind Bardot was that once you strip the fancy JS and CSS away, you were left with a semantically correct basic website, with the index file being just a list of thumbnails that were linked to an HTML file for the detail of each page.

That way, search engines could catalogue your content as if it were any other good linked-page netizen, plus you could split the larger images and more complex content out into the individual pages, making the index page as quick to load as it could be.

The Bardot layer sat on top of that, parsing the index page, and carrying out an ajax look-up on the spread you were currently viewing to retrieve the page files. It then parsed the page to find the larger scanned pictures to replace the tiny-res thumbnails and finally substitute any page specific HTML over the top of that.

That was the philosophy - keep the index file as a super-basic list of linked thumbnails, then pull in the detail from the page files when required, or to put it another way, don't mess-up the distinction between the index file and the content files.

The trouble with that is perceived speed. Doing the page transition and several ajax substitutions (remember, looking at one page spread could mean pulling in two or more individual pages) at the same time was a no-no. The combined processes made the transition look clunky, even on a fast desktop computer. The only sensible way to do it was to carry out the transition with the blown up thumbnail in place, then do the ajax substitution afterwards (using a setTimeout). This gave a slick transition and a kind of pleasing resolution upgrade afterwards as the full res page appeared.

But in truth, that still sucked. Going to a page that was a blown up 48px thumbnail and waiting up to a second for the full res page to appear was a crappy experience if I'm honest.

Plus I'd moved away from writing flat HTML pages for everything (creating and maintaining 100s of files with no errors was an obvious nightmare), and was now generating the index page in PHP by stepping through the file system. That meant I could spot the full-res scans and embed links to them in the index page if I wanted, I didn't need to ajax and parse a page just to substitute in a hi-res image.

While I was at it, why did I need the individual page files at all? Why not load it all into the Index? That would have been a step too far. The higher res scans weren't the only things in the page files, but notations, links to other web content, and hidden OCR'd text areas for indexing. Loading that into the index file would have made it huge, slow to download, slow to parse, and rubbish to index.

So I compromised and muddied the philosophy a tiny amount for the sake of speed. The page files are retained, but I'm now entering the links to the hi-res scans into the index file (in a hidden <span rel="link"> tag). That means I can swap the thumbnails for the high-res scans much faster because I don't rely on any ajax request to be carried out first, and only pull in the page file after that swap.

The effect is noticeable, perhaps not overly in these low-framerate videos, but clear in the browser. When you go to any page, the high-res is almost always ready and waiting for you. Even on iOS.

It's a happy philosophical compromise, and means I'm pretty much done with page transitions. Next stop is offline caching.

[atomoco-blog]

Here's a quick vid of a test version of Bardot running on an iPad (including camera reflection and glare). It's running a 25 spread, 46 page magazine in Safari, although it runs in "standalone" web app mode as well, which dumps all the Safari chrome.

Although the hi-res page loading is slow, thats more a problem with web server speed (ie, MAMP on my overloaded MacBook).

The "skim" navigation ribbon acts slightly differently on a touch device than on the desktop. The desktop version pops-up thumbnails of pages as you hover over them, then clicking a thumbnail throws you to that page. Touch devices don't have a hover state, so you move your finger over the thumbnails, then release when you're ready. For some reason, it seems right to offer a confirmation dialog before you go to that page on a touch device, but not on a desktop. It just makes sense to me that it happens that way.

[atomoco-blog]

Benchmarks

I've been getting into the Bloomberg Business magazine iPad app recently. The content is varied and interesting, the subscription price entirely reasonable, and the content design is beautiful. But as an app, it's sloow. Start-up is toe-tapping, touch gestures can be hit and miss, and page turning is a bit jerky (Let me put this into context by saying I'm using an iPad mk1 with an "unreleased" version of iOS).

Compared to that experience, Bardot was feeling pretty speedy.

But then a colleague showed me the National Geographic mag app, which had that true "you push the pixels" feel to it. Transitions were instant, swiping pages buttery smooth. It reminded me of the first time I downloaded the Wired Mag App. It felt like the future (until I realised the content wasn't that compelling, the delivery mechanism poor at best).

And my benchmarks for what feels like a native app has altered.

Must try harder.

[atomoco-blog]

Bardot needed a method of page navigation that's familiar to most users and easy to use. In this test it's the drop down ribbon of pages that we've all seen before in other apps, both native and web.

There is one slight difference in that the width of the ribbon is representative of 100% of the publication, and the tab (or "bookmark") moves to show you your progress through it. It seems so obvious, someone must have done it before, but I haven't spotted it yet.

In the video, as normal left/right controls are used, you can see the bookmark moving along the top edge.

Hovering over the tab reveals the ribbon, which represents each spread as a white dot, changing to a thumbnail as you mouse over it, and clicking any spread will jump you to it. Also note the "ghost" bookmark that follows the thumbnails as you mouseover them, and that the "real" bookmark chases it when you click a thumbnail.

I like this method as it combines the navigation and the progress indicator into one interface, without making it too cryptic.

In an ideal world, you'd see the thumbnail without having to mouse over it, but if the width of the window is supposed to represent 100% of the publication, the thumbnails would be overlapping so much (or so tiny), that the interface would just add to the confusion.

The fun is in making this ribbon interface work with touch controls - but I'll walk through that another time...

[atomoco-blog]

Bardot's flexible spreads

All the browser manufacturers crow about the speed of javascript in their implementation - but a central tenant of Bardot is that it leans on CSS as much as possible - because CSS is way more optimised at resizing and positioning DOM items on a page, then a huge javascript class being parsed and run.

This test shows a few test pages in horizontal mode (where it displays "spread-by-spread"), then vertical mode (where it is "page-by-page"). In truth, imagine these two modes as portrait and landscape on a tablet.

Most of the flexible spread/page layout is tamed with CSS with javascript only defining a few container sizes to keep it appearing as full screen as it can be.

Note the spread with three pages, that was a bugger to get right. It would have been easier to have assumed that all spreads were a maximum of two pages wide, but you can imagine the potential of displaying a fold-out diagram that is multiple pages wide, so I wanted to bake that capability in right at the beginning, rather than try to retro-fit it later.

You might notice the way the pages start low-res, then ping into hi-res. That's because each page starts as a small thumbnail (stretched to full-screen), which is substituted for the high-res images only when you're looking at that spread, to keep the memory footprint low - especially important on iOS devices where the images are handed off to the GPU, in a publication that could be hundreds of pages long.

[atomoco-blog]

The joys of web development. A CSS test in Safari on 10.7 and Safari on iOS5. Don't exactly look the same. [sigh]

Keep going!

[atomoco-blog]

Project Bardot

When I first toyed with the idea of working for myself again, I played with two potential projects. I called them "Brooks" (which I'm still working on), and "Bardot". Bardot was never really a direct money spinner, but it was the most fun. And as much as my sensible side wanted to shelve it, I've found I just have to scratch this itch before I can carry on.

As mentioned in a previous post, I really want to see an HTML5 magazine app framework that shows that selling a monolithic, non-web-accessible magazine native-app is not the only,  or smartest, way. This is Project Bardot. What I've got is less of a brief, more of a manifesto:

Make an HTML5 web-app framework for reading digitised books made up of scanned pages to allow the simple dissemination of copyright free/expired content in an enjoyable digital form.

Do not silo the infomation, but make it searchable, indexable and most importantly vieweable on any web browser enabled plaform. The user experience may vary, but the access to the information will not.

Make it feel fast, native-app fast.

Design a minimal user interface that doesn't get in the way of the content and that the audience enjoys using.

Offer the possibility of adding annotations, links and some rich content to enhance the scanned content.

Allow offline reading where possible.

Not try to achieve too much too quickly, but keep it simple. Start with the core idea, don't try and make a complex publishing system that rivals commercial systems. That may come later.

Try not to "own" the framework or monetize it directly, but open source it instead. Partly because the whole point of this is to provide a way of freeing lots of great content that currently sits in dusty drawers, and I want the barrier to that goal to be very low. And partly because a framework like this is a potential copyright law nightmare where charging for it could be akin to stealing from other parties. Oh and partly because I've used other people's free frameworks for years, and it's time to give something back to the community. That doesn't mean I won't look into ways of getting paid in some way, but it won't be through restricting access to any code.

I'll be talking through the issues of attempting to make such a thing as it comes together (we're already on the way), and releasing the code to github as soon as it's good enough to warrant it.

Happy days.

[reillybrennan]

Even a URL tells a story

[atomoco-blog]

reillybrennan:

Apple iPod URL: http://www.apple.com/ipod

Sony Walkman URL: http://store.sony.com/webapp/wcs/stores/servlet/CategoryDisplay?catalogId=10551&storeId=10151&langId=-1&categoryId=16178 

Sony’s War-and-Peace URL is what you see even if you just type in Sony.com/Walkman and hit go. They can’t produce that page for you without all of this business at the top. Apple’s URL is really clean, isn’t it? 

I like when companies think about the ancillary parts of their experience like this.

[atomoco-blog]

Lion & iOS, trucks & cars

I like a lot of OS X 10.7 Lion, but a couple of details bug me. Well, not me, as much as I worry it will confuse the hell out of the average user.

The new "disappearing scrollbars" and having the "natural scroll direction" on by default will be guaranteed to initially confuse 90% of average users at their most basic understanding of computer user interfaces.

I find that pretty strange, understanding the changes to both of those UI ideas rely on a geek that actually thinks through what they do - as oppose to the bulk of the public that can only use a computer UI from rigid existing learned behaviour, and will find it tough to adjust.

On iPhone and iPad, those metaphors are fine because users have understood them from the beginning of the platform. On Macs, they're quite a shift in the basics.

Then Steve Jobs "Trucks & Cars" metaphor came to mind. If Apple is considering OS X as moving towards being a "truck" (i.e. for the higher-end user), could they be looking at the Mac audience as moving towards the higher-end, that would understand these changes better than the general public?

Is Lion the first "pro-sumer" targeted OS X, now that Apple is selling so many iOS devices to the average user?