Where to start?

I’ve been reading a fair number of books on the subject, including Luke W.’s Mobile First and the Sitpoint’s catchily-named Build Mobile Website and Apps for Smart Devices. However when I’d got beyond the initial sketching and wireframing stages I found myself at a bit of a loss as how to proceed until I decided there was no point worrying about the “app” side of things, I could just prototype in HTML and view via the browser.

No problem. However, after a day and a half of building some basic HTML screens I found myself bogged down with things such as icon size and resolution for the iPhone’s retina screen (I have an iPhone so am concentrating on designing for this, at least in the first instance). The work I’d done just wasn’t looking very convincing. I needed to up my game a bit if I was going to get anything done by the end of the week which led me to me to my next discovery…

Use a framework

Although I’d heard of various frameworks I’d more of less discounted them due to the fact they seemed like overkill and I’d have to spend a bunch of time getting up to speed with them before I could create anything. However I was at the stage where I thought they were worth another look. I looked at Sencha Touch for about five minutes before I went cross-eyed and then settled on jQuery Mobile which seemed much more lightweight.

Although jQuery Mobile does that jQuery UI thing of inserting a whole bunch of extra markup and styles into your code it does at least give you a load of common design patterns and interaction styles. Also, let’s face it when you’re prototyping it’s best not to get too hung up on final design but boil things down to key interactions and navigation flows.

Mobile design is not web design

Sounds almost too obvious to state but the reason I do is it’s interesting how much you really have to change your mindset when you approach a mobile app. This is not web design, it’s not even responsive design. Throw everything out and start from scratch. User flow and navigation become more important than ever. Just working out where the navigation should go in different contexts can be pretty challenging (hint: not just at the top and the left).

Get others involved

I’m lucky enough to know some talented developers who are keen at giving this whole thing a go too, which is handy given that about four days in I’d felt I’d gone as far as I could. Although I toyed with the idea of setting up some basic database I realised that this would soon make me quite angry and not a nice person to be around so I decided to drop a couple of friends an email.

Talking to someone else really helps put things in perspective as well as providing some practical advice about how to move forward.

Next steps

So, the next steps are really to get back to basics: firm up the storyboards which can be quite illuminating in showing you the screens you’ll need (hint: a lot more than you probably initially thought). Once this is done, pass these on to others to take a look at and put a big black marker through anything that’s going to take too much time and set priorities. Then, some short, concentrated sprints to create some basic prototypes we can actually show people and see if it’s something they’d actually use.

So, overall this has been a worthwhile exercise, even if what I’ve learned is I know less about this area than I thought!

[Featured image: 1896 Swedish telephone, from Wikipedia].

I’ve found a couple of newish tools particularly useful for creating moodboards: Pinterest and probably more so, Gimmebar. Whilst these don’t do anything essentially different from some other tools I’ve used like Zootool or Evernote I particularly like the way they present your saved artefacts and their minimal interfaces seem–to me anyway–to be well suited to quickly grabbing and dumping stuff.

Pinterest

At the moment you need to have an invite to join Pinterest but it’s not too difficult to get one: I requested one via the website and received one the next day. Once you have an account you can invite friends along too. The idea behind Pinterest is you create boards which you can pin things to–either images you’ve found on the Web or you can “repin” from other people’s boards.

I found some interesting examples of other people’s moodboards by searching Pinterest which I was able to pin to one of my own boards.

As the concept of boards underlies the whole app it would seem a natural tool for creating moodboards. However I’ve had some problems with performance: it’s a been a little slow at times which has made it a little frustrating to use. But maybe those are just teething issues.

Gimmebar

Gimmebar allows you to create collections, similar to Pinterest’s boards and allows you save various kinds of artefacts: images, videos, full web pages and status updates.

The main advantage of Gimmebar for me is collections can be private or public–so you can create a “private stash” of stuff you’ve found without having to share it by default with the outside world. This gives it more of a notebook feel to me so I don’t feel so self-conscious about creating some kind of finished product. Also, the ability to save a complete web page from header to footer rather than just a predefined or viewport size is a really useful feature.

Like Pinterest, Gimmebar uses that “jQuery Masonry” style of tiling to present results which means it’s easy to browse the stuff you’ve saved and get more of a sense of the overall feel of your collection–making it easier to take editorial decisions on what fits and what doesn’t. I prefer this to say, Zootool’s approach to presenting same-size thumbnails (although as a visual bookmarking tool I think Zootool’s great).

You could share this as your moodboard–either by publishing it or sharing it as a collaborative space with other Gimmebar users, although I like to add a little more editorial control by downloading the images and using them in a Photoshop comp. Here’s one I made earlier:

There you go–pretty straightforward. What do you use?

The lack of network connectivity fitted in quite nicely with themes of two of the presentations. Robbie Manson‘s “The Mindful Designer” encouraged us to step away from our tools, think better and make the most of the teams we work in; think “positive disruptions” rather than the negative ones like the constant interrupting communication flow of Tweets, emails and RSS.

Denise Jacobs delved deeper into this, explaining via a story the different mental states we experience. As someone who’s been interested in the benefits of meditation for the past year or so  it was pretty cool to see them being discussed (or at least alluded to) in a mainstream design conference. The brain’s “alpha” states are associated with increased learning, greater creativity and flow. Simply closing your eyes will start the process of entering this state. Playfulness triggers the right side of the brain; gamma states are associated with insights– these can be triggered by laughter. So, according to Denise: to get your creative groove back, breathe, play, laugh. Sounds alright to me.

The conference kicked off with Dan Mall asking us to explain what we do. This set the tone for the rest of the day, getting us to think about exactly what design is: “adding form to a shapeless idea”, mending what’s broken (Naomi Atkinson), making interesting and exciting stuff–after, ahem, loosening the f up  (Travis Schmeisser), making things better (Trent Walton), eliciting emotion, inducing action and affecting change (Cameron Koczon) or getting from A to B (Frank Chimero).

If any common themes did emerge I think they could basically be summarised as:

• just make stuff–you don’t need a startup and you don’t need to make anything perfect (and let’s face it there’s nothing like a bout of IE7 CSS fixes to kill the excitement of an idea);
• give back–as designers we’re in a privileged position to get involved and help out our local communities, education or health service (although they were some murmurings of this veering dangerously towards “Big Society” territory).
• teams are good–make the most of the people around you, whether this is your co-workers or the design community.
• Now is a good time for design and design-led startups.

So, turn off the Twitter feed for a moment and think: what do you do?

[Featured image credit: NACONF2012 by Paul Robert Lloyd on Flickr].

With this in mind I thought it was time to move away from nailed-down desktop-favouring fixed width grid designs and venture into the slightly scarier world of responsive fluid grids. As I always learn better by doing than by just reading I decided to create a example website and go through the whole process from planning to coding, which I’ll share here in case you’re interested (of course you are!).

There’s quite a lot to this whole fluid grid business so I’ve broken up this post in to two sections: first we’ll consider how we might approach a responsive design conceptually and at the visual design stage; in the second part we’ll look at turning the design into HTML/CSS to see it in action.

Some definitions first…

I’m going to be concentrating on fluid grids in these posts rather than responsive design per se. So, what is a fluid grid? Well, let’s think about what we mean by grid first. Wikipedia defines the typographic grid as,

a two-dimensional structure made up of a series of intersecting vertical and horizontal axes used to structure content.

Sounds reasonable to me. In print (or fixed width web design terms) these intersecting axes combine to produce modules or units of a predictable fixed size with which to construct your layout and give it consistency and rhythm. When we go fluid the units–I’m going to use this term rather than “modules” to avoid confusion down the line–will still structure the content consistently and predictably but their size and positioning will change depending on the available size of the rendering device’s display.

We should be clear than fluid grids are not in themselves responsive web design. Responsive design is a combination of a number of elements, fluid grids being one, the others being the use of fluid images / media and the use of media queries to load in CSS depending on screen size.

Designing for responsive, er, design

You could use fluid grids in an old-fasioned fluid design where the grid units resize according to screen size, but in a true responsive layout it’s likely your grid will reflow when the screen size changes. For instance, a 16 unit wide grid may be fine on a desktop or laptop browser but an 8 unit wide grid may be more suited to a tablet (or a desktop browser at a smaller size) and a 4 unit grid to a mobile screen. Of course it’s not just a case of halving the amount of grid units on a screen and moving the remaining content on to the next line: it takes more thinking than this to ensure your desired content hierarchy is reflected at different resolutions. One of the reasons that true responsive design is pretty demanding; but that’s good, right?

Introducing our sample site

The site I’m going to be using is a real site for a project I’m currently working on for a basic HTML/CSS framework simple enough for designers to do rapid prototyping with but powerful enough to use for proper site builds. SPIL (simple powerful interface library) is written in HTML5 and uses OOCSS concepts to make code easy to get to grips with and maintain. But, more of that later. SPIL is due to be released under an open source (BSD) licence and will have its own website containing information about the project, a download link, documentation and a gallery of projects built with SPIL. Nothing too complex.

This is our Photoshop comp showing what the user will see on a desktop-size screen: a 16 unit grid taking up 960 pixels of screen width.

Before we launch off into fluid grid land we need to make some decisions about the kind of devices and screen resolutions we’re going to support and our audience. Well, luckily we can bypass a lot of the user research you might normally do at this stage as we know the users most interested in this are going to be designers and front-end developers. So we want to ensure we cater for our highly tech-savvy audience and make sure our site looks good on desktop, tablet and mobile.

Let’s consider the contexts in which people might be looking at our site. Again we’re going to make some assumptions here based on our own knowledge and experience. If you want to download a framework and play around with it, chances are you’re going to be on a desktop or laptop. However as we know that the web world will be all-abuzz about SPIL (yes, I know, just pretend ok?) let’s imagine (try hard now) that people will be sharing it with others at conferences and meetups. So our design should reflow to display clearly and usefully at the kind of resolutions we’d find on tablets and mobiles.

We’ll call our target layout sizes “desktop”, “tablet” and “mobile” but of course this is a little misleading as a desktop browser is capable of displaying all of them depending on its viewport size; likewise a tablet browser could also be resized to show the lower size.

Content hierarchy

Before we can make any design decisions we should think about our content hierarchy and what will be important to different users.

Let’s look at our comp again. We’ve got four rows with 3-4 groupings of information on our main “desktop” layout. Let’s categorise them below (leaving aside the header and footer).

Row “A” (About):
1. What is SPIL?
2. How does SPIL work?
3. Download button
4. News

Row “B” (Documentation):
1. Code example one
2. Code example two
3. Full list of tutorials

Row “C” (Examples carousel)
1. Screenshot one
2. Screenshot two
3. Screenshot three

Row “D”
1. Credits
2. Licence
3. We love (links to other sites)

“Tablet” resolution

As we’ve got less screen real estate on a tablet we need to think about structuring our content accordingly: we still want the most important information most prominent. We’re going to use a 8 unit wide grid for our tablet design, half the amount we’re using for the desktop.

Arguably the download button is not so useful for tablet users as they won’t be working with the framework in that environment. However, remember that this resolution is also available for desktop users and we don’t want to assume that tablet users definitely won’t want to download the files. So we’ll want the first row to display our initial row “A” information about SPIL but will move the “download” and “news” section to the row below thus:

A1  A2
A3  A4

We’ll handle the “documentation” section in a similar way:

B1  B2
B3

Our initial row “C” is a carousel of three images. We’ll make this smaller for our tablet design, just showing two of the images at any one time:

C1  C2

Our initial row “D” can be reflowed thus:

D1  D2
D3

Our mobile design

We need to think more carefully about our mobile design: we’ve obviously got even less space than for the tablet design so we want to be cautious about what we show.

We’ll be working with a 4 unit-wide grid for our mobile design. We’ll reflow our initial row “A” information accordingly:

A1
A2
A3
A4

For our initial row “B” information we’ll do some editing. We don’t want our page to appear too cluttered on a small screen so let’s dispense with the “teaser” code examples and just list out our tutorials:

B3

In terms of example websites we could decide to edit these out entirely or just display one image:

C1

For our initial row “D” information we’ll just stack these on top of each other but for the sake of a more concise page we’ll leave off the links to other sites.

D1
D2

So, would you bother creating Photoshop visuals for these design as it’s tripling the amount of work you need to do? I guess it would depend on the size and scope of your project and the client you were working for. But in our case we’ll just use our sketches to inform how our layout and content will reflow at lower screen sizes but will do all the work in-browser.

So, so far we’ve thought about what a fluid grid is and how it relates to the area of responsive design. We’ve also thought about our site’s content hierarchy and how we would want to present this at different screen sizes. With all this considered and documented it’s time to move on to the only place we can see responsiveness in action: the browser. But that’s for next time!

[Featured image credit: grid by Mike Smail on Flickr]

Firstly–a disclaimer. These are entirely personal and largely anecdotal observations–I haven’t exactly undertaken widespread research on the topic so there’s bound to be work which I’m ignorant of. Ok…

Understanding the domain

What is digital humanities (DH)? I imagine you’ll get a different answer depending on who you ask but a good starting point might be the Wikipedia entry:

The digital humanities is an area of research, teaching, and creation concerned with the intersection of computing and the disciplines of the humanities.

In practical terms DH projects usually involve the creation of scholarly digital publications, more often than not now delivered via the Web. This has often equated to digitised texts, manuscripts or other source material of use to a small, specialised audience of researchers. However, this is not necessarily the only application of the technology in the field–some projects, whilst retaining scholarly rigour in their production may have a far wider user base, both in terms of their creation and consumption.

For instance the Great War Archive project undertaken at Oxford University, and its sister project in Germany run by Europeana created a crowd-sourced digital collection of memorabilia, documents and ephemera from the First World War. A diverse range of participants were able to contribute objects to the resource, either by uploading digital images via a website or by attending sessions in which people could bring their collections in for examination and digitisation. Some were also able to make connections and construct their own stories from the data.

I’ll admit a personal preference for the more “participatory” end of the digital humanities–simply as I’m excited by the potential of the Web to involve and, hopefully enthuse a wide range of people. However, whatever the type of resource being created, as all good designers know it will only be truly successful if designed for the needs of its users, whether they are a narrow selection of specialists or a much wider audience of non-specialists.

Approaches to user experience design in the digital humanities

Whilst I can’t speak for every project, I imagine it wouldn’t be massively unfair to say there is some reluctance to adopt wholesale user-centred design techniques in all DH projects–for a number of reasons, including some you might encounter in other fields: it requires time, effort and money to be done properly and sometimes funding and deadlines are tight.

However I think there are other reasons too. Culturally DH projects have been led by a particular research agenda rather than the desire to produce a “product” for a set of users. For this reason projects can often be rather vague in their precise aims at the outset, so resources may be the result of collaborative research between the technologists and non-technologists rather than built to a pre-set specification.

Related to this, academic staff involved in the projects may have a strong idea of how they want to present their findings–after all, it is their area of specialisation and they may not see the value of involving others; or they may simply make an assumption that others will use the resource in the same way they do–a common pitfall for the creator of any software.

There may also be a question of expertise–digital humanists themselves may not have the relevant knowledge of human computer interaction and interface design simply because they are highly skilled specialists in other areas (e.g. mark-up languages or text analysis). As DH projects are largely led by technologists it can be difficult to sell them on the value of design–which they may see as simply making something look pretty.

So, why bother?

All resources are (or you would certainly hope be) created for a purpose, and by association have a group of potential users. Understanding this from the outset and designing a resource appropriately can surely greatly enhance the impact and amount of use it receives (of course if your target is “future scholars” then it might be a little more difficult!).

It’s also worth thinking of a digital resource as being more than data. Data is generally stored in formats (e.g. XML or databases) that can be reused or even divorced from its presentation layer and archived. I see resources as a combination of this data, tools to interrogate and make sense of it and interfaces which allow users interact with the data–something which necessitates the involvement of the people who will be using them in the first instance; otherwise resources run the risk of being unused, unusable or simply esoteric experiments which soon disappear from view.

Current work

While it seems to me user-centred design is a relative newcomer to DH, things are certainly happening. Although focus groups and last-minute usability testing have certainly been used in the past, more robust approaches to user experience appear to be gaining more ground within the discipline: one indicator being more academic articles appearing on the subject.

Also, as I noted in an earlier post there is some very innovative participatory work going on in what might be considered DH’s more democratic/populist sister discipline: digital museums. Museum users are being encouraged to interact with institutions and their collections in more and more creative ways. In order to do this user-centred design processes are being adopted enthusiastically; something DH will no doubt learn from, especially as it adopts similar techniques to build resources (see for instance the Ancient Lives crowd-sourcing project to transcribe papyrii).

The Ghosts of Gone Birds is a project to “raise a creative army for conservation” — highlighting extinct species of birds and raising awareness of current conservation issues — via exhibitions and events. All of the proceeds go towards the work of Birdlife International.

I went along to a night of poetry and music at Rich Mix London (featuring amongst others the damn fine experimental folkies Walking with Ghosts) and also got to the exhibition just round the corner, at the Rochelle School in Shoreditch. This ran over a couple of floors and featured installations and paintings from a number of artists, including Ralph Steadman.

There were various notices around in the exhibition positively encouraging the taking and sharing of photos — a nice touch I thought.

The presentations covered a wide range of topics relating to digital museums, from planning a realistic digital strategy to refining your metadata but those I found of particular interest related to engaging and involving users in building and using digital resources, a topic I’ve been finding myself more and more interested in of late–addressing those nagging questions about exactly why and for whom we in the digital cultural heritage and humanities sectors are building these resources in the first place.

Museums and galleries arguably have a head start when it comes to involving users in projects: direct access to them as visitors to their institutions. This is something that the Social Interpretation project at the Imperial War Museum (IWM) is making the most of: a project to record visitors’ interpretations of exhibits, bringing them the same ability to share and discuss found on the social web to the museum space, via in-museum devices, the web and mobile apps.

This project is putting the user at the centre of the design process, both directly via testing of prototypes and observation of user behaviour in the galleries.  Interestingly, it’s also been run entirely according to an agile methodology–not just the development but the design and management, so I’m really looking forward to hearing more about this.

Another participatory IWM project being developed is Lives of the Great War–a crowdsourced project to create stories of those who served and died in the First World War. This is being done principally by enabling access to the various appropriate information sources distributed across the Web, some of which are behind paywalls, via a single access point. The plan is to archive the resource permanently and also to release the data under a “CCO” licence (the most permissive Creative Commons licence); making the data available for reuse in a number of contexts.

The Outside In project, run by the Pallant House Gallery is a slightly different participatory project–providing a space for artists traditionally unable to engage with the artistic mainstream due to disability or social circumstance to display their work. The interface for doing this was developed iteratively, including in workshops with the artists themselves. The next stage is a mobile app–not for the sake of developing one but because interaction via a mobile device involves fewer cognitive steps, e.g. the need to understand concepts such as file structures when uploading content from your computer’s file storage. With a mobile app, the device which records the art work can also be used to upload it directly.

I was fortunate enough to be elected to the committee of the conference’s organising body, the Museums Computer Group–something I’m very excited about. The levels of innovation and creativity in the sector are very impressive and I’m looking forward to learning and sharing more with all involved.

Over the last few months I’ve been increasingly impressed by the Object Oriented CSS (OOCSS) approach to coding CSS, adopting the methodology as far as I understood it for one freelance project I worked for and in the redesign of my own website.

When I took on the project of updating the front-end development framework in my current workplace it was no surprise then that I decided to base it both on the OOCSS philosophy and parts of the CSS framework (there is a subtle difference). I thought it was about time to record my thoughts on using it so far and give my take on some of the issues that have arisen.

Why OOCSS?

OOCSS is a different methodology for writing CSS which is far saner than most of the other approaches I’ve used in the past. In a nutshell, OOCSS:

• encourages re-use of CSS styles across a site
• uses the concept of CSS “objects”, that is predictable code based around the content that object will contain
• instead of endlessly creating new styles, uses the concept of extending styles
• discourages the use of location-dependent styles where possible

If that sounds a little abstract, it really means adopting a set of coding practices (and mindset). Here’s just a few examples:

Never style on IDs, only on classes

Styles on IDs cannot be reused as you can only have one ID per page. Classes on the other hand can be reused any number of times. IDs also take higher precedence than classes, so using them can soon lead to specificity wars in your stylesheet (the nuclear option in which is the use of the !important declaration,  an indication you’ve just entered a whole new world of pain)

Use classes where you can

Another way to start a specificity war is to over-use location-dependent styles, i.e. by cascading styles down via containers. Instead, create a specific class (NB this might not always be possible or practical — more on that later).

Extend styles

Let’s say you have a style for a box and want to create a slightly different style for another box — instead of creating a brand new style, simply extend an existing one. For instance, have a base class for one kind of object and extend it by providing extra style declarations in an extension class, e.g.

<div class="stupidBox box1"> I'm a stupid box </div>
...
.stupidBox { width:200px; height:200px: border:1px solid;}
.stupidBox.box1 { background-color:#ccc; border-color:#333;}

Hang on,

You can’t throw out location-dependent styles just yet

Ever worked with a CMS? Chances are the answer to that question is “yes”. In which case you’ll be dealing with CMS-generated content appearing in at least one predefined area of your page. Which means you’ll need to be using the cascade to ensure the content is styled properly — yes, location-dependent styles.

Ok, location-dependent styles aren’t wrong per se, the trick is to handle them so they won’t cause specificity issues in the rest of your stylesheet. To do this cascade them from elements nearby rather than further away (think containing classes, certainly not IDs applied way up in the page).

I’ve created some reusable styles — but what happens if my site design changes?

Once you get into OOCSS you may get swept away with excitement at the levels of abstraction you can build in (if you don’t get out much that is). Need a load of different inline lists? Create an inline style instead of applying inline styles to each; want to apply CSS3 box shadows to an element — just create a box shadow style.

Yes, there is the danger you can end up with a bunch of presentational styles that will suddenly won’t fit your new design (e.g. two of those inline lists are now block level lists, the box shadows are just so out). This is a particular danger for larger sites which might undergo a number of design interations without substantially changing the HTML output.

Be pragmatic

In my experience redesigns usually (no, scratch that, always) go beyond CSS tweaks and style refreshes to something more fundamental which will involve a larger code overhaul.

That’s not to say you should get into the habit of creating purely presentational class names but it is important to think about the level of abstraction you want to go to.

For instance I always create an inline list style as it’s such a common design need. However, I’d think twice about creating styles such as .redBox, .dropShadow or abstracting out common typography styles (e.g by creating a .fontFamily1, .fontFamily2 class etc.).

Grids

Similarly, and a problem not confined to OOCSS is the use of grid systems. I use the OOCSS implementation of grids as the basis for creating my own grid layouts. However, “out of the box” these are designed for desktop browsers and are not responsive so will not always be the best fit for mobiles or maybe even tablets.

Having said that there is no reason that they cannot be made responsive by gradually loading in resources depending on screen resolution. Going mobile is often a case of looking beyond the technology anyhow and concentrating on what you want to serve up — in some cases this may be a subsection of content styled (and structured) very differently to the desktop experience.

My implementation of OOCSS

Thinking in terms of OOCSS has led me towards code modularisation. In a multi-skilled environment it’s not just the designers and front-end developers who are creating HTML, but also often the back-end developers.

By thinking in terms of objects I’ve found it more straightforward to break down code into pluggable chunks which developers can take from a growing snippet library.

Predictability of code structure makes it easier to implement common design patterns and for others to pick up and run with others’ code. Consider a block of code for implementing tabs (and with apologies to the OOCSS authors, I’ve chosen to use “modules” in a slightly different way to theirs).

The structure of the code reflects the needs of the particular plugin I’m using, jQuery Tools. However, the class names for the elements of this particular module are generic enough to be able to be applied to different implementations (although for the sake of saving development time you may want to agree on the use of a common set of tools, whatever they may be).

A tabs module

<div class="mod tabs">
 <ul class="tabControls inline">
  <li class="tabControlHeader"><a href="#tab1">Tab one</a></li>
  <li class="tabControlHeader"><a href="#tab2">Tab two</a></li>
 </ul>
 <section class="tabContent" id="tab1">Tab 1 content</section>
 <section class="tabContent" id="tab2">Tab 2 content</section>
</div>

CSS

Unless your sites all look the same it’s probably harder to have a CSS library tied into this beyond basic resets and common presentational classes (or maybe recipes for vertical and horizontal grids), but at least CSS authors will have predictable code objects to work with.

No silver bullet

I don’t believe any framework is a silver bullet and every site build is inevitably going to be a series of compromises but I think this is a positive step forward away from the nightmare of CSS bloat and specificity headaches.

Still, the Kindle’s weaknesses are really its strength: in my view it’s good for one thing and one thing only — reading with no distractions. And at that it pretty much excels. The electronic ink display is amazing. When I first got it out of its box I thought I had to peel a sticker off before I used it, not realising it was actually in sleep mode and displaying one of its wallpaper images of famous authors.

I don’t claim to understand how the E-ink works but it looks pretty close to a printed page, making it a complete joy to read. The iPad may be streets ahead in every other respect but are you really going to want to read a book on a back-lit screen — I know I wouldn’t. If you want a comparison between the two displays (literally under the gaze of a microscope), check out this blog post: Kindle and iPad displays: up close and personal.

So, I’m undecided what I’m going to use it for. My main reason for justifying it to myself was I could use it as a way of catching up on all those blog posts I never get round to reading. If you use Instapaper you can download your subscriptions and email them or transfer them via USB to the Kindle, meaning you never need to feel guilty about hitting the “Read later” button again.

I think it’s also the natural home for tech books, well at least the ones that don’t have high production values and pretty photos — which is most of them. I might try some newspaper / magazine subscriptions too (come on Guardian, your iPhone app is fantastic, it would be great to have some kind of Kindle version too). Although I’m still attached to printed books in so many ways I could imagine reading a novel on it too, so we’ll see.

I bought the Wifi only version and to be honest can’t really imagine any situation in which I’d need the 3G. I have tried to read my Gmail via the browser but to be honest it’s about as much fun as stabbing a fork in your head so I think I can live without instant Web access.

Originally posted on Posterous (6 November 2010).