joking aside

May 19, 2010

I rather like using real-world, but made up, examples in prototypes, wireframes, mockups and other user experience bit and pieces. I think it provides a reviewer with a content familiarity that means they are not distracted by confusing ‘Sample 1, Sample 2, Lorem Ipsum 7’ style placeholders. I mean, are those labels important, or is a reviewer expected to try and read a bit of Latin to get some context around the content blocks I’ve scattered around? Much easier to use a few scannable labels and text areas to allow a reviewer to filter and forget, rather than expect them to somehow instinctively understand that the drop-down list of ‘Attribute 1’ to ‘Attribute x’ that you’ve presented them with is just to suggest an interaction style and that the data isn’t important. Just ignore the data. No, it isn’t actually going to say ‘Attibute 1’, that’s a placeholder. Well, it will probably be ‘Edit’, or ‘View’ or something. Look, we’re getting away from the purpose of this review. etc.

However, there is another reason to use real-world, but made up examples, which is not directly out of the usability engineering manual. Its where you put the jokes. That’s not to say the placeholder text for the latest portal home page prototype for your financial services client should start with ‘There was an Englishman, an Irishman and a Scotsman…’, but there is a little bit of me that wants to leave the occasional blipjoke lying around for anyone determined enough to look at the 3pt type in the sub menu of the fly-out on page 17. Its a bit like that bloke in Blade Runner leaving a little origami joke in a abandoned lift shaft. It doesn’t matter if you miss it, but there’s a nice little subtext to be discovered if you want to.

It goes back to my final year usability engineering presentation at university which included that Framemaker clip art of people with no faces, and all I could think of doing to lift the tedium of my Jakob Nielsen thesis was to add a speech bubble which said ‘I’ve got no face’. At that point in the presentation proper, I left it unreferenced, projected on the wall, as I wittered on about interaction models for process management application interfaces on UNIX, and I saw the sideways glances to each other of my tutors and the slight curl of their ‘snapped to geometry’ mouths and I knew they’d discovered it. They sat so far forward in their chairs from that point on that I could see the labels in the necks of their C&A shirts. I knew I’d got a first.

Actually, I cocked up my computing maths module, so I only got a 2:1, but hey, who asks about your degree once you’ve finished it? Anyway, back to the jokes, for this morning I came across a rather nice one, which prompted me to blurt all this nonsense. If you take a look at the Thunderbird 3 Features page, there’s a little example image of what those evil phishermen get up to and how Thunderbird protects you from it. What I rather like about the example is who its protecting you from. Correct me if I’m wrong, but someone had a little smirk putting that example together.

listening post: foals – spanish sahara

wireframe storyboards

April 15, 2010

someone told me the other day, well, it was Chris actually, that they liked the wirefames I was working on because they told a good story. they’re not the actual words he used, it was much more thoughful and pondering on the back foot than that, but that was the gist of it. either way, that comment resonated with me, if I allowed to use a word like resonate, or resonated, because it captured the essence of what the wireframes were about. I’ve produced wireframes many times in the past that do just describe the physical location of application elements and the specific interactions that are required to be supported. you know, like, ‘this button can only have 2 words in it, it is next to the other button, and when a user presses it, the four horsemen of the apocalypse gallop over he horizon, which we will probably implement using AJAX’. that kind of thing. my preference, however, is to develop wireframes that do that, to a lesser extent, but are much more like storyboards that describe a sequence of events in a way that can be easily visualised. now, I’m not talking about a set of images that describes Avatar 2 – All Your Trees Are Belong To Us, but the storyboard metaphor works at a much simpler level where I can walk stakeholders through a visualisation of the key interactions, including detailed UI elements, that, I think, makes understanding the interactions and changes in state much easier to grok, if I’m allowed to say grok, which I just did, kind of out loud. they’re closer to design comics than wireframes, except they have wireframes in them. but with speech bubbles.

it doesn’t work for everyone. I’ll work on these with interface designers and application developers who will undoubtedly need to understand exactly how I anticipated that left-hand tab device working when it appears, in my wireframes, to overlap the chrome, or something, and ‘wanted a wireframe, not a bloody AHA video’, but hopefully, providing the context within which the interface elements sit and the describing their interaction through the storyboards, it all makes more sense than just presenting a page with a static diagram on it and saying ‘build that please’. I’ll soon see.

listening post: aha – take on me

android user experience

April 14, 2010

see what I did there? no? it doesn’t matter, you’re not even reading this.

since I’ve recently twisted my own arm into spending more than 2 quid a week on my mobile phone, which was actually 2 quid a week on a sim card which was hoofed into a handset from 1999 running symbian s60 which I didn’t like when I was using it and like even less now that I’m not, I’ve been wondering how I might somehow get into experience design for mobile platforms. I’ve been designing for web and web-based channels for donkey’s years and more recently working on complex applications for trading platforms, but I’ve not really delved deeply into mobile as yet, other than the wap sites we pushed out for Sun Microsystems many years ago which amounted to 17 links in 5 languages that didn’t really go anywhere, but we did make the logo really much smaller than we were supposed to, which, in itself, was a triumph of vectors and transparency.

a few weeks ago, I was interviewing for a user experience design position with Qualcomm, which was to be working on their next-generation mobile platforms alongside and incorporating brew, plaza and lots of other nice things that you rarely see in carphone warehouse, but that position went the way of many other full-time permanent user experience positions. that’s to say it didn’t go anywhere at all. I was phoned before the second interview to say that the position had somehow vapourised internally by law of the corporation and that they were very sorry but it just doesn’t exist now so you can’t do it. despite it not coming to anything it did at least pique my interest, since I did my usual copious research on the subject in order to perform well at the interview I didn’t end up doing.

what has piqued me even more, if there are levels of pique, is that when I started my current position at Tobias and Tobias, working for financial services clients in the city, was the fact that not only does almost every single person on the train, on the tube, walking down old broad street or sat in bishopsgate, own, and is permanently conjoined with a smartphone of some descrption, they own, and are often conjoined with a smartphone of some other description. at the same time. and three on the go is not as uncommon as you might imagine, or at least I imagined. for at least 70% of these people, bleating into an iphone is their preferred interaction, for which the pied piper of hand things is undoubtedly most pleased, but other smartphones are available. you know that. right? and with all these smartphone appendages dangling in front of me, I feel like I’m missing a trick if I don’t get some kind of experience designing for those platforms.

now I’m one of those people doing the train, tube, hammersmith, broad street, bishopsgate, liverpool street, tesco thing, I thought I really should get some kind of proper phone which lets me monitor trades on an AMOLED screen or something. or at least doesn’t hang for a full minute when I send a text. since I also have a tendency to avoid technology trends (meaning, usually, I can’t afford to be an early adopter), I had, a long time ago, discounted an iphone. actually, I like iphones, but anything that requires me to use bloody itunes just doesn’t make it onto any list I have. apart from the list of things I won’t buy that I have. and, since I’m already a google person, I was already looking for a phone built around a mobile platform that integrates all my googlist activities which of course is the moble platform that google make. it was really just a question of handsets and platform versions. which, granted, isn’t an insignificant consideration. suffice to say, after I’d bought a pile of ‘what mobile’ magazines the size of a small child and reviewed acres of adverts with the occasional technology blog in the middle, I’d determined that the HTC Desire with Android 2.1 was the very thing. which it is.

I really rather like Android. I really rather like HTC’s Sense UI, although it really doesn’t do an awful lot after you’ve worked out you don’t need to flip between 7 home screens that often. and I really rather like the Desire, even though its a bit, well, brown. all three together, notwithstanding the usual caveats around battery life, seem to support an all-round user experience that suits the way I want and need to use my smartphone to do the things I bought it for. my most basic requirement was for excellent support for multiple email accounts that exist on multiple servers. I was also looking for excellent social network integration. I was also looking for excellent clocks. truth is, limited as the Android apps store is, there’s just enough there to enhance the user experience by one or two degrees. mind you, the apps bundled in 2.1 and the google support built-in, means that I’m pretty well set up without needing to go anywhere near the app store. unless I want better clocks. for which there is probably an app. called ‘better clocks’.

in a nutshell, which is kind of what my new phone reminds me of, first impressions of the Android user experience on the HTC Desire are very favourable. I’ve had a week to do the thing where you turn everything on and then turn everything off again. I’ve tried all combinations of widgets, programs and shortcuts. and turned them all off again. I been through every single setting screen and religiously observed the state and behavioural changes that occur as a result and determined whether I like those changes. I’ve settled on a default configuration for everything. I’ve installed the advanced task manager to kill everything I’ve left running, because, excellent as multitasking is and nice as it is to have updates and notifications going of all over the place all the time, is does rather reduce the usable uptime.

next step is to work out how I might begin to design and build something that runs on my own phone, just to go through the development process. with all that spare time I have. I’m writing this on the train you know. and my tea’s gone cold.

listening post: echo and the bunnymen – the cutter

wireframe data for situational awareness

April 1, 2010

if that title means anything at all. I’m quite pleased with it, but I suspect I just completely made it up, but then I suspect Jakob Nielsen completely makes things up sometimes.

as I’m constructing multi-state wireframes for a client, we’re uncovering all sorts of user expectations that we simply hadn’t considered when we started. which is nice. we also uncovering lots of interaction issues that we didn’t know we’d have because we didn’t really know what components we’d be using. which is also nice. more interestingly, we’re finding that we’re discovering some assumptions about behaviours are not correct and that is being uncovered by the made-up data I’m cramming into the wireframes to illustrate real-life scenarios.

in previous wireframe specifications I’ve completely abstracted the data into ‘item 1’, ‘attribute 1’, ‘attribute 2’ and ‘metadata x’ type labels, which do make your wireframes very neat, which I do rather like, but don’t adequately convey to the client just what they might expect to see at a particular component or object level, in a particular state. I don’t know all the data attributes in a complex trading system, of which there probably thousands, but I do know at least the highest few levels of the taxonomy that enable me to make reasonable assumptions about what is a meaningful and relevant set of data for a given object in a given state. so I’m throwing a few of them into the wireframes to illustrate state changes and assess user expectations.

while I was thinking this would be useful to demonstrate real-life application states, I was really using it as a device to increase the comfort level of the clients, by enabling them to make the subtle change in situational awareness from abstract to operational, which sounds like a grand statement, because it is. I tried to make it sound more like a joke, but I couldn’t work out how do do that and still make the point, which I’m now veering from. what it actually uncovered is that the assumption I’d made about some of the metadata that might be attached to a particular item was, in fact, not quite correct. that’s not to say it wasn’t correct metadata, it just wasn’t the metadata that users would actually find as useful as other metadata. which is fine. that’s why I sit with the clients and clarify their expectations. but the net result is much more than just me going back over 17 pages of visio layers and multi-clicking into shape groups to select the attribute text.

the subtle difference in the choice of metadata that is meaningful at that particular state of a particular application panel didn’t just change the label, it changed the whole focus of a subset of user interactions. what we had assumed might be a focus on creation date of an object, was actually much more about the distribution of that object, meaning that we’re not tracking the object by time, but tracking it by recipient. its not when, its who. and when that change is extrapolated across functional areas such an entry points to searches, reporting, and at a more granular level, iconography and semantics around context and labelling, it changes much more than just shape 97.

so its as well that I used that real data, even if I just made it up. ‘attribute 1’ just wouldn’t have prompted the discussion. I mean, I’d be finished by now, but we’d be building something inherently broken. like my computer. which is a different story.

listening post: dj shadow – mutual slump

hidden complexities

March 31, 2010

well, they’re not very well hidden. I mean, you can’t hide things you haven’t defined yet.

I’m currently developing wireframes for UI specification based on user activity flows for applications for a client in financial services which is a sentence a bit more complex than I had anticipated when I started typing it even though I suspected there were elements to it that I hadn’t even realised might be necessary in order to provide context that might make it rather more full-featured than the initial scope I had in my head. which goes some way to providing a metaphor for the user experience design conundrum I’m facing, if, in fact, a conundrum can be faced. its not an unusual problem. I’m designing a solution for a problem that can’t quite be fully articulated. as I iterate on user interaction descriptions and map out user action flows and try to develop wireframes that support those interactions that can be translated into functional requirements for application development, its clear that the initial, narrow scope for must-have features for go-live of version-one don’t tell nearly enough of the story to enable me to successfully capture all the core interactions, let alone the extended feature set that adds the value to applications that might actually convince the business that they really should use it thereby making all this effort worth making.

and this is a complex environment. it is a number of degrees more complex than most web-based, rich internet applications. as a single application that is part of a broader application framework that supports a wide range of trading activities, it is actually a quite small, discrete deliverable, but even that small, discrete deliverable, in the operating environment in which is is embedded, has an interaction model that is as big as you feel the need to define. you could easily take a number of weeks or months refining the activity flows, building scenarios, iterating wireframes and doing all those things you do to try and ensure that the user experience is as engaging and intuitive as is humanly or machinely possible and still, on each iteration, and at every review meeting, you’ll find that there is another enormous chunk of user operations that you didn’t know about yesterday and that chunk begets another chunk and that other chunk requires an altogether different contextual description to enable you to understand its operation and how the user interaction model might need to be considered if, indeed, we are to include this chunk you’ve just told me about in the initial release, which we are, because we actually want it all now.

but this isn’t a bad problem. this is a good problem. as a user experience practitioner, the reason I do what I do is that I like to solve problems and provide elegant solutions. what I don’t like to do is take somebody else’s solution and just draw boxes and arrows around it. in this case, I get a complex problem and I’m asked to provide a simple solution – an excellent user experience – and how I solve it is up to me. perfect. I’m travelling more than five hours a do to do it, and they want it yesterday, but, really, minor irritations when to put them on the balance against job satisfaction.

listening post: attic lights – never get sick of the sea

agile user experience design

March 26, 2010

if you’re subscribed to about 27 job searches like I am and are very specific about the nature of your search parameters, say, ooh, I don’t know, ‘user experience Norwich 100+ miles’, even though you end up with a list of java developers and IT managers in Stevenage, then you’ve undoubtedly seen a proliferation of job specifications that on the surface look like exactly the kind of thing that matches your skillset and you’re just about ready to call up that recruitment consultant who likes using capital letters and concatenations of job titles repeated every other word throughout the advert, when you see, near the end of the page, the ‘Agile’ word. as in, ‘must have experience of working in an Agile environment’. or ‘Agile experience required’. or ‘we follow an Agile development methodology’. or ‘Agile Agile Agile Agile Agile Agile‘. or something like that.

this is fair enough. I applaud the adoption of a structured methodology to support a development process since I know just what a creepy mess it can be to not follow any method at all. and Agile looks like its a reasonable software development practice. it means you do things quite quickly. I can do that. I can do things quite slowly too, but if there’s a team dynamic and a project management style that encourages rapid development and lots of meetings where you stand around each other’s desks pointing at widgets and occasionally breaking out to the whiteboard that doesn’t have any pens, then that’s fine. but just because you do that, it doesn’t mean you’re necessarily following an ‘Agile’ methodology. I mean, its ‘agile’, as in, you’re able to make decisions, act upon them, and reset the project outputs with expediency, but, you know, it might not be necessary to attach a label to it and market it externally as that. you don’t have to have a capital ‘A’. because as soon as you do, you’ve changed the job description entirely.

the role I’m in now is pretty agile. working for clients in the city on software development projects that require daily collaborative sessions on user journey development and wireframe builds necessitates a rapid, robust style of user experience design. I’ve had the luxury, in previous roles, of having lead time for development and intervals of checkpoints measured in weeks, when in reality, a couple of days was probably more sensible. for this project, however, there is a definite urgency, not least driven by expenditure, that requires that the user experience design iterations are compressed into daily outputs and reviews. I can’t say that I prefer working one way or the other, although the day-by-day cycle definitely drives increased output and, as yet, doesn’t appear to impact either the focus on the user or the quality of the output (he says, doing that breathing on his fingernails and polishing them on his chest thing).

so why am I bothered about what somebody calls their particular working environment, when it really doesn’t matter, since it doesn’t effect the ability to deliver engaging, meaningful user experiences? because that word is a barrier to employment. that’s why.

barrier 1: ‘I don’t see that you’ve got enough Agile experience’.

this applies when you sit with a development team as part of over 3 hours of face-to-face interviews for a user experience role at a software house in a corner of a business park somewhere between an A-road and another A-road, and are told they work in an ‘Agile’ environment, whereby they do all those things I’ve just mentioned with each other’s desks and whiteboards with dry pens. in this case, no amount of discussion on my part about working to suit the environment and being fine with daily scrum meetings and managing sprints and workstreams and swimlanes or whatever, manages to persuade them that I can work in an ‘Agile’ environment. because I can only demonstrate that I could work in an ‘agile’ environment. I can’t actually check the box, that I probably designed in the first place, that says ‘Agile (make sure its a capital)’. or they just didn’t like me. which is equally likely.

barrier 2: ‘I don’t see that you’ve got enough Agile experience’.

fair play that if after half a day of talking to real people in a stuffy conference room about a role that they then use the ‘Agile’ thing to let me down. at least I had an opportunity to demonstrate that I was the right candidate. at least I was across the threshold. at least it was a team of people who at least have their own understanding of what ‘Agile’ means. this is just a mild annoyance. in contrast, what really gets my goat, even though I don’t have one, is the creeping proliferation of ‘Agile’ as a keyword in job descriptions posted via recruitment partners on behalf of clients. this nastiness is much worse, because it actively excludes potential candidates before they even have the chance to demonstrate their worth. it is the doubled-edged sword of internet recruitment whereby I might maximise my presence in searches or on recruitment portals by ensuring that ‘user experience’ or ‘information architecture’ or ‘UX’ or ‘IA’ is a key attribute such that searches will find me. and that’s pretty successful. mind you, you can probably find me if you search for ‘Norwich’ and ‘idiot’ or something, but that’s a different user altogether. the downside of optimisation in this case is that I don’t use the ‘Agile’ keyword to enable a higher ranking. that’s to say, when those machine-driven CV scrapers are trawling for candidates based on a job description with ‘User Experience’ in the title and with ‘Agile’ as a keyword requirement, I’m probably not on the list. unless its for a job in Norwich. which it never will be. why not just add ‘Agile’ to my CV? because, in fact, and to the point, I can’t honestly say I’ve worked anywhere that has used the ‘Agile’ word, despite the fact they might be ‘agile’, so I don’t use the word. It would be a lie.

barrier 3: ‘I don’t see that you’ve got enough Agile experience’.

slightly more galling than not even getting onto a shortlist is getting onto a shortlist managed by an agent acting on your behalf who understands what ‘Agile’ is marginally less than they understand what’ User Experience’ is. I have to say, I have come across some excellent recruiters at some excellent agencies, and they really understand the marketplace and the applicability of roles to my experience. but they don’t manage all the client relationships. there are numerous black holes I’ve been down whereby the only application route is online to an agency I’ve never heard of to a client I don’t know, based on a job description I quite like the look of (which, coincidentally, pays going rate). after falling through the silent vacuum for a few days, not really getting any indication of application status, I might endeavour to find out what’s going on. if I’m lucky, the application process will have yielded a phone number for the recruiter which means I can actually follow it up. if I’m unlucky, I’ll contact them and they’ll say ‘yeah, I saw your CV, but I don’t see that you’ve got enough Agile experience, and they said they were looking for that, so I didn’t feel I could put you forward’, or ‘yeah, I saw your CV, and they liked the look of you, but they didn’t see you had enough Agile experience, so they didn’t select you for interview’, or ‘Tim Caynes? What job was that? User Information what?’ . its the human interpretation barrier that is the worst. I’m reliant on a third party communicating to a forth party about my personal experience and applicability when they have to negotiate around a keyword that neither they understand or I believe should be a gating factor. or they just didn’t like me. which is equally likely.

as Rob said the other day ‘Agile? That’s just working quickly, right?’ I can do that. Do I need to pass an exam or something?

listening post: the who – 5:15

gainful

March 15, 2010

as in employment. I’ve recently started working for Tobias and Tobias in London doing lots of nice user experience work for some rather nice clients in the city and its a rather nice change from just looking for work in London doing lots of nice user experience work for rather nice clients in the city.

its a significant change from the working environment I have been used to for the last few years, in terms of office space (there is some), project management (there is some) and stakeholder relations (there are some), but the core requirements of the role are essentially the same, that is, to understand the business requirements and define the user experience that supports and encourages engagement, streamlines interaction, and drives business growth, oh yes. and gets it finished by last thursday. based on the changes we just made to the requirements. in the meeting you weren’t at.

that last bit was a joke. I was at the meeting.

listening post: the rakes – 22 grand job

well, this is embarrasing, firefox

March 4, 2010

I used to put hidden messages in programs. I’d wait for unsuspecting users to generate an error and then display something like “I’m sorry, you can’t do that, that’s rubbish”, or “Please enter a number. Not a name. Least of all your name”, or “Boing! Not Correct!”. but then, see, I was just writing some subroutine in a telnet client or something which only worked on a single server that a handful of people had the misfortune to interact with. I was young. it was funny. once.

since then, I’ve often seen similar mildly-amusing-once-if-that messages generated by alert conditions or error messaging in applications that I’m trying to use to achieve some workpath goal. not necessarily a particularly important goal, but all the same, its during an interaction I’m having using an application I’m trusting to just enable me to get on with it. usually its just a trivial cuteness, like an ‘oops!’ when I’m trying out the beta of brizzly and it fails to do something because the twitter api has prolapsed. sometimes its more terse and slightly more annoying, like a ‘something is wrong’ followed by a calamitous fail that condemns my unsaved spreadsheet formulas to an inglorious uncertain document recovery undeadness. but sometimes, its an overly smug acknowledgement that something went wrong but, hey, its ok, because things go wrong, right? we don’t know why, but, you know, never mind.

I do mind. I am slightly irritated that it is acceptable that an error condition can be apparently rendered less important simply by adding a spoonful of pith and a continue button. I’d almost prefer a window.open() with a stack trace dump in it, which, if you don’t know what that is, is as dull as it sounds, but at least its specific, and relevant. the latest incarnation of this creeping error-as-friend experience that I’ve been invited to share is the ‘well, this is embarrassing’ condition as blarted out by the most recent release of firefox. simply put, if firefox crashes unceremoniously, probably because my laptop battery has run out or something, then the next time it starts, it throws a mini hissy fit and refuses to load the tabbed content it apparently knows that it should be loading. which it finds embarrassing. maybe not as embarrassing as the fact that I seemed to be preoccupied with pubs and hardware last time firefox crashed, but, ooh, sorry, a bit embarrassing, all the same. I mean, the rest of the error is quite specific and possibly even quite helpful, but nonetheless, the context in which it sits is now one of over-friendly banter, which does nothing to reassure me at all.

I might be being a tad over-zealous. after all, its just a little jokey headline. but I’ve now seen it about 9 times. and its starting to grate. and that’s my point, such as I ever make a coherent one. be careful where you pith.

listening post: ladyhawke – my delirium

walk this way

February 19, 2010

those lovely looking people with the astro-turfed terrace at archibald ingall stretton obviously understand that if you really want to find them, you probably know how to use your own map, and so they have instead provided you with the more immersive user experience of doing the walk for you, so you know what to expect. it tells me everything I need to know about a daily commute from the nearest tube station in a way that Transport for London really never can, complete with pithy social commentary on, amongst other things, the relative worth of free news (although I might have recycled).

try for youself. I rather like the journey from Tottenham Court Road.

listening post: aphex twin – flaphead

in praise of flickr. again.

February 17, 2010

I have, a number of times, errantly extolled the virtues of the flickr user experience to such an extent that I am probably some kind of fan-man. that is to say, I’ll often be asked what I consider to be a good example of user experience design, when, frankly, its sometimes easier to explain to people what I do by demonstrating what it means to a user in a practical application, rather than a more ethereal dissection of human computer interaction and the history of pointing at things with disconnected devices and why I chose orange for a headline. notwithstanding the feature creep of recent years and the freakout that was the acquisition by yahoo! which was erroneously blown up into some kind of photo-apocalypse, the flickr experience is still one which supports everything I want to do in a way that I like to do it and doesn’t ask or compel me to do things I don’t want to do in the middle of things I’m half way to accomplishing. it is still, 5 years or so after first using it, one of the very few sites I access without going via some kind of API and amazon cloud captcha interface which abstracts the operations and allows me to fiddle about and aggregate any number of similar services so that I forget what I was doing in the first place much like writing this sentence. flickr, the site, is, of course, its own presentation layer on top of its own services, and so is only one of a number of full-featured experience architectures that I might decide to opt into or somehow leverage. but, in the end, its the seamless integration of those services, the consistent, coherent application of visual design components and the logical, meaningful management of data and taxonomy that pulls everything together so neatly. and I can write little notes with smiley faces on. there can’t be anything better than that.

there are some features of flickr that I never use. galleries. favourites (much). but then, I know they’re there if I choose to opt in, but on a daily basis, they don’t interfere with my operations. this is probably because I’m not very popular. I expect that insanely popular flickr users are bombarded via notifications of additions to galleries, favourites, and invitations to groups like Sword of Damocles ur got exceelent PIKTUREs add 1 comment on a billion animated gif 600×600. but then, you can decide what to do with those notifications, and anyway, if you’re insanely popular, you probably have to deal with the popularly insane, but at least flickr will provide you with the tools to manage that effectively and efficiently, but the good folk at flickr understand scalability and the effects on user operations. at least, I think they do. I mean, with about 6000 photos a minute or something getting uploaded and each one of those objects existing as a unique entity with all the associated user operations, I’m thinking they’ve considered scale.

in the end, as far as flickr is concerned, I’m just a satisfied user. and I pay for the privilege. and I don’t often say that.

listening post: catherine wheel – black metallic

Things what I writ