Richard Pope Profile Photo

Richard Pope

Articles

    ∞

    Product Land (Part 1)

    You can’t build what you can’t think of in the first place.

    This is the first of a couple of posts about why I think we need better ways for thinking about the design of digital products.

    Thinking in a linear way, in simple hierarchies or in timelines, is pretty simple for us; our brains evolved in a world with 3 dimensions (plus an additional one for time), but for more complex systems, systems with many dimensions, we tend to need tools and concepts to help us.

    As an experiment, think about evolution for a few seconds. What picture do you have in your head?

    Was it this one?

    That image, from a 1965 popular science book, goes by the name of ‘The March of Progress’. It shows the supposed progression of the evolution of humans.

    Or maybe the first picture that jumped into your head was of a fish hauling itself out of the sea using its fins as legs?

    The idea of linear progress, of directional change, is a stong meme, but in evolutionary terms is also not very helpful. In Wonderful Life, a book that is part story of early life on earth, part the detective story of recreating the bizarre world of the Burgess Shale from 2.5 dimensional fossils, Stephen J Gould dedicates a whole chapter to detailing the damage it has done.

    Maybe you had a branching tree in your head, with species on each branch? Though slightly closer to reality, it is still far from an accurate representation. Genetic diversity and evolution by natural selection are inherently multi-dimensional and as a result we need tools to think about them properly.

    In The Blind Watchmaker, Richard Dawkins uses things called ‘biomorphs’ to do just this.

    Biomorphs are computer generated critters created under a simulated evolutionary pressure. They can vary from each other in 9 ways (things like width, branching, height, colour).

    You can play with creating biomorphs using this javascript implementation and watch Dawkins explaining them on this 1987 episode of
    Horizon    . (both recommended!)

    Biomorphs

    Biomorphs exist in ‘biomorph land’, a many-dimensional space that contains every potential biomorph. Similar biomorphs are clumped together; radically different ones more distant. It is a space you can take a mental walk though understanding how patterns change over multiple axis. In turn, biomorph land is a tool for understanding a more complicated space:

    There is another mathematical space, not filled with nine-gened
    biomorphs but with flesh and blood animals made of billions of cells,
    each containing tens of thousands of genes. This is not biomorph space
    but real genetic space. The actual animals that have ever lived on
    earth are a tiny subset of the theoretical animals that could exist.
    These real animals are the products of a very small number of
    evolutionary trajectories though genetic space. The vast majority of
    theoretical trajectories though animal space give rise to impossible
    monsters. Each perched in its own unique place in genetic hyperspace.
    Each real animal is surrounded by a little cluster of neighbours, most
    of whom have never existed, but a few of whom are its ancestors, its
    descendants and its cousins.

    Sitting somewhere in this huge mathematical space are humans and
    hyenas, amoebas and aardvarks, flatworms and squids, dodos and
    dinosaurs. In theory, if we were skilled enough at genetic
    engineering, we could move though the maze in such a way as to
    recreate the dodo, the tyrannosaur and trilobites. If only we knew
    which genes to tinker with, which bits of chromosome to duplicate,
    invert or delete. I doubt if we shall ever know enough to do it, but
    these dear dead creatures are lurking there forever in their private
    corners of that huge genetic hypervolume, waiting to be found if we
    ever had the knowledge to navigate the right course though the maze. We
    might even be able to evolve an exact reconstruction of a dodo by
    selectively breeding pigeons, though we’d have to live a million years
    in order to complete the experiment. But when we are prevented from
    making a journey in reality, the imagination is not a bad substitute.

    Biomorphs are used as a stepping stone to paint a picture of a huge hanger containing every actual and potential organism suspended in the air. A hanger you can take a mental walk though, a couple of axes at a time.

    It works with other concepts too. Try and imagine a ‘musical-instruments-with-strings hypervolume’, imagine it has an axis for number of strings, one for volume, sound, methods of playing, tone, colour, country of origin and so on. We can only glimpse a couple of the axes at any one time, but along them we might see all the guitars and banjos in a clump and the bowed instruments as a cluster with the hurdy gurdy sitting just out from them, along with all the other instruments that have never been lying inbetween, some viable, some that would make your ears ache.

    For a reverse example, try and imagine all the axes that existed in Jeremy Deller’s History of the World before it was squished into two dimensions (geography, musical genre, political systems, historical events, synthesisers).

    The History of the World

    What does this have to do with digital products though?

    My proposition is that digital products are also inherently complex and inherently multidimensional, that design is too often constrained by our methods of thinking about them and too often risk being either derivative or simple iterations of variants as a result; or worse, user needs are never met as well as they could be because we are looking for solutions in the wrong place.

    Products can vary along many axes - the degree to which they are active or passive, centralised or federated, specific or generic, solitary or social; they can vary in the technology used to build them and on which they are consumed, the power which they create or remove from users and the organisations we put around them. The number of potential products dwarfs the ones we ever conceive of, while many will be nonviable, some will meet user needs. We need ways of exploring the potential space products could occupy, tools for embracing the margins of potential products, tools for walking though product land.

    Things like the much-tweeted Spotify diagram of how they build products are just too simple, too linear; they are the equivalent to the March of Progress (and almost certainly doesn’t do justice to the thinking the team actually put into their products).

    Even the standard build-test-iterate-repeat loop diagrams feel unhelpful, since it is too easy to fall into the trap of picking one thing, one broad concept and iterating the hell out of it, making sure every feature is as perfect as it can be, without ever again questioning the core approach (or maybe that you need two or three coexisting products or 2 equally good ways of addressing the same user need, just as convergent evolution has solved flight in pterodactyls and parrots, fruitflies and hummingbirds). Product land remains unexplored, user needs unmet.

    Some digital industries seem to be particularly stuck, shuffling around a single idea, the equivalent in animal space to assuming the only animal that could exist was a hyena (albeit with slightly different markings).

    My favourite examples of this are the digital products we have at our disposal for finding work and finding a holiday (though there are many others). In both of these industries almost all the products seem to be clumped around one small area of product land. Some tools may be slightly better than others, but they are all essentially variants the same product.

    Finding a holiday online almost always conforms to the pattern of choosing a departure airport, a destination and a price range, then seeing a list of results. So you are pretty well served by existing products if you know where you want to go from and to (and want to do it by plane).

    Finding a job online consists of entering a search term into a centralised system and getting some results back in a list. The search is generally free text and searches against a subset of the jobs available online, the ones the product knows about, which is in turn a subset of the available jobs in society at the moment, since many (most?) jobs never make it online. There is a bit of variation, but most products conform to this pattern.

    Better products for people to find the best holiday might not be that important in the great scheme of things (unless you run an online holiday finding service), but better tools for people to find work is good for almost everyone (people find jobs and get paid, companies find employees, government pays less in out of work benefits and the economy generally functions better).

    You are currently pretty well served by existing products if you know the type of job you want and where you want to work, which generally means having some employment history. In short, if you don’t fit that description, the market fails you.

    Part 2 will try and imagine some alternative viable products in these spaces and the sort of tools we can use to find the edges of product land.

    ∞

    Music notes: September

    ∞

    OpenStreetMap as infrastructure - a localgov map?

    The Moabi project is reusing the tools of the OpenStreetMap project to map natural resource use in the Democratic Republic of the Congo. This is an example of what Mikel Maron (from the Moabi project) and Elizabeth McCartney (from the US Geological Survey) called ‘OpenStreetMap as Infrastructure’ in their recent talk at State of the Map US ie taking the OpenStreetMap tool-chain and applying them to new problems.

    I got to experiment with some of the OpenStreetMap tool-chain at bit during recent work at the Land Registry and, now in its 10th year, the OSM tools are really impressive:

    • The core OSM website is a solid product providing storage of geospatial data, history of changes, user accounts etc

    • The new in-browser editor iD is very simple to use, and is pretty easy to customise (I think this is the where Moabi have done the bulk of their customisation)

    • There are various tools for rendering map tiles, checking data quality, and importing and exporting different formats

    Above all though OpenStreetMap is a set of tools for building consensus around ‘things in space’.

    Which brings me onto local government. Local government has lots of information about ‘things in space’: the extents of conservation areas, redevelopment zones, dates and times of bin collections by area, locations of air-quality stations etc.

    Some councils helpfully publish this data online. The best have done the hard work to clean the data, convert it to open standards and figured out the licensing. Lambeth Council even publishes areas with protected vistas of St Paul’s Cathederal as GeoJSON.

    The trouble is - publishing, quality and format are patchy and inconsistent between councils and that makes reuse harder.

    So here’s the proposition: could the OpenStreetMap tools be used to build a LocalGovMap? Not necessarily as the definitive source of data for evermore (although I guess it could be), but to build consensus about what local government datasets should look like, using a single collaborative space.

    A similar approach is working in central government, where designers from across departments are using wikis to figure out the best way of designing user interface elements. So why not across local council officers who are the custodians of geospatial data?

    I doubt it would take much. Probably a couple of councils coming together and a month or so of a Ruby on Rails / javascript developer (the core OSM website is written in Rails, and the iD editor is a javascript app).

    ∞

    Info-buildings

    Lambeth town hall - mockup with

    Image derived from (cc) martin allen

    Lambeth Council are asking residents with digital skills to help them improve the services they provide. As part of this, that they are holding a hack evening (which, annoyingly, I can’t make, hence this blog post).

    One of the challenges is:

    how can we make it easier for people to engage with the council in decision making online, particularly those who aren’t that comfortable using the internet?

    Government, particularly local government, has buildings, physical presences in its communities. Why not use those buildings to show the work that is going on in them? Turn them into info-buildings.

    Info-buildings are not new. The Ayrton Light sits on top of the Elizabeth Tower (aka Big Ben) to show when parliament is sitting. On the other side of the river, the London County Council displayed unemployment figures on a large billboard on the roof (for agitation rather than engagement, but still a similar principle).

    As the difference between offline and digital become increasingly academic, rather than treating them separate realms, why not merge the two? Use buildings and data together for transparency and engagement:

    Use live data to display what the council is currently voting about on the side of the town hall, so people passing can better understand the work that goes on there; show a sparkline of the housing list waiting list on the side of Olive Morris House; advertise SMS numbers of open consultations to people can vote from the top deck of the bus.

    The technology to do this is relatively simple - see this article on ‘Projection Bombing’ - so it should be doable, at least as an experiment, at a relatively low cost.

    [Note: I’m not advocating doing this without permission!].

    ∞

    Music notes: August 2014

    ∞

    MOO.COM UX rules - circa 2008

    I wrote these up just before I left MOO I think.

    == General principals ==

    === Optimise for the common case ===

    Adding something to satisfy the needs of a small number of users confuses the rest. The tools we build should satisfy the needs of the majority of users.

    === Build tools that on meeting one simple need ===

    Tools should focus on solving one problem e.g. “Signing up for a newsletter”, “Previewing a pack”. If a problem can’t be articulated in a single sentence, rethink the problem, there’s probably more than one thing that needs building.

    === Build tools for users without experience ===

    Tools should be easy to use for users those without experience of our websites, and meets users initial needs.

    === Users needs are not always the same as the features they ask for ===

    Nothing elese to say here.

    === One action per page ===

    Stick to 1 action per page (search, crop, signup), with clear escape routes / next steps.

    === Context is more important than consistancy ===

    Giving users the most useful information, at a given point, is more important than consistency across pages e.g. changing a sidebar based on where you are in the site is good if it bubbles up useful content to the user (see Ready Made).

    === Optimise for average user’s return rate ===

    Tools that people use on a daily basis need to be designed differently from ones that people use only occationally.

    People using tools regularly have more time to learn, and need shortcuts for repetitive tasks. Iconography and and more complex user paths are fine for them because they have time to learn how they work.

    Occasional tools need to be straightforward at first glance, their use transparent on first glance, with a small number of simple text hints.
    Too many features can make things harder to understand at first glance. As can iconography or shortcuts that they have to learn the meaning of first before they can use them.

    === Make a pages functionally readable ===

    You should be able to give a page a single scan and work out what it does. The most important thing here is the order and prominence of elements. e.g. closing your eyes, them opening them and see whether they jump to the page elements in the order they should be used.

    === Only tell people things once per page ===

    Do not repeat instructions to people. For example, if you have an area
    of a page where you can drag items to, do not have text at the top of the page AND within the drag area explaining what a user needs to do.

    === Contextual help is best ===

    Help text and hints should be placed as close to the relevant page element as possible. e.g. If a page element needs some explanation
    that it should be dragged, then place the text “Drag to crop”. Hiding help text in popups is bad.

    === Let people teach themselves ===

    Let people figure things out for themselves by making sure the most
    obvious action is something you want them to do. This is better than longwinded explanations. E.g. the photo picker page has little text, but almost the only thing you can do initially is drag something.

    === Keep the user path as short as possible ===

    The user should be presented with the shortest path to their goal. the exception to this is where a valid business case can be made for extending it.

    === Make decisions for people ===

    Giving people endless choice confuses. Make some choices for people and let them focus on the things that are really important to them. e.g. doont give people a choice between 10 fonts that all look the same.

    === Make people confident in their actions ===

    Explain to people what is about to happen to them e.g. “Want to add more images? your crop positions will be saved”. Explain how many steps something is going to take and where they are in a process / navigation system.

    == Pages make sense before and after action ==

    Or “Designing for empty”. If an area of a page is going to change after a user’s action, explain what is likely to happen and use it as space for a hint. e.g. a floating button that says upload, with no context of what it is uploading is bad. A simple box with “uploaded files will appear here” does the job (hide the message after first upload).

    === State should always be maintained between pages ===

    The state of a page (i.e. any actions made by a user) should be
    maintained between postbacks and when returning to a page.

    === Make sure pages content can be linked to forever ===

    If pages have to be removed, then redirect to somewhere useful.

    == Specifics ==

    === Placement of controls ===

    Primary action buttons (Save, Next step, etc) should be placed at the bottom right of the screen.

    Checkboxes should be placed to the left of their label.

    As a general rule, if there is more than action on a page, and not of equal importance, the most important should be a button, the rest links.

    Textbox hints (“e.g. your name” next to a name field) should be placed to the right of text box using a tag. For Textareas they should be placed underneath.

    === Warnings and errors ===

    Error messages and warnings should be straight to the point, polite and written in plain english. People are not computers (i.e. “Unhanded exception” is not a good error message), and should never be made to feel stupid.

    All error messages should be displayed using the red box at the top of the page. The only exception is if the user has failed to make as single action on the page and it would be impossible for them to proceed. e.g. they need to uploaded some images but have clicked the “next step” button without trying to do so. In this situation the user should be shown a javascript alert() box.

    === Hints and text ===

    All headers, hints and control labels should be written in sentence case. Hints and help text should be short and straightforward to understand and should never been hidden from a user (e.g. under rollovers or popups).

    === Drag hints ===

    Areas of a page where something can be dragged on to should have a grey inset dashed border 3px wide.

    === Page headers ===

    Index pages (/products, /Flickr /Ideas) have a graphic header and a strap line, pages further down have breadcrumbs and a header.

    === Validation ===

    All pages should aim to be valid xhtml. If a page doesn’t validate it should be for a justifiable (e.g. the only way to implement a piece of functionality)

    === Links ===

    Links should always be underlined, unless htey are part of a top-level menu system.

    ∞

    A recipe for starting & prototyping new projects

    1) Know your history.

    Whatever you are making, someone will have done it before, using the tools and thinking of their time.

    Start with Wikipedia and work out from there. If the Wikipedia page doesn’t exist, create it. Search for old literature and design assets. Be on the look out for useful quotes and concepts.

    Sketch from the digital by default standard 2012 project

    2) Read the legislation.

    Read the legislation.

    Even if it’s long and boring, read it all. Understand what is law, what are regulations that can be changed, what is just convention.

    If you can code, try to write out the core of the legislation in code/pseudo-code to help understand the domain. If you can’t code, find someone who can and ask them to do it and get them to explain what they think.

    3) Draw the thing

    Aim for something that represents the totality of the service - a mental model for yourself, and something to help you explain it to others.

    If you can’t draw, that doesn’t matter, almost no one can. If you are more a ‘words person’ than a ‘picture person’, draw do not write, there is too much ambiguity in words on their own.

    Try drawing a mix of screens, process and concept. Avoid clichés like pyramids and concentric circles. While sketching have half-an-eye on what technology, what tools and what skills might be needed to make it.

    Keep drawing until you have something that is just-about-convincing and that you are able to re-draw consistently and quickly. Then stop. Do not make it too complete or too polished. Do not reach for Photoshop or Power Point - people will see it as an end product rather than a tool for getting there.

    4) Understand the state of technology

    Technology can drive product development as much as user need and design. Open Streetmap came into existence 10 years ago in part because of affordable consumer GPS units; bespoke on-demand printing services because of high-quality digital printers. Who knows what Web RTC and other decentralised technologies are about to do to how we use the web?

    Spend time understanding the state of technology and design right now. Assume it has changed since you started your last project and that your knowledge is out of date.

    Add at least 10 new RSS feeds to your RSS reader (setup an RSS reader if you do not have one). Actively seek out ideas that you can steal to solve the problem at hand. Pay particular attention to changes in browser technology.

    5) Seek out metaphors.

    The metaphors we have available to us influence the things we make and how we think.

    Spend time actively seeking out and thinking of concepts that, in turn, help you think and communicate.

    For example - starting a suspension bridge, isostatic rebound, intelligent personal assistants, recommendation engines, z-indexes.

    Post-glacial Rebound

    Don’t take them too literally, they are just tools for thinking.

    Isostatic rebound, - Image (cc) Mike Beauregard

    6) Keep notes, share notes.

    Start keeping notes in something simple and sharable like Evernote a Google site or wiki. Put notes and links from legislation and historical reading in there. Start collecting anything even tangentially related to the project. News articles, screen grabs of UI patterns you might steal, technology that might be useful. Photographs of sketches. As more people join the team, share the archive with them.

    7) Keep a list of user needs.

    Make a list of the top things that users might need from the service based on what you have learnt so far. Ideally do this as a small group (no more than 4 people). Write them on index cards and put them on a wall to see if any obvious groupings emerge.

    The aim is not to make a complete validated list, or a process, that will come later. It is to start building a picture and to start understanding what is lacking.

    8) Sketch in code.

    Build a prototype with as small a number of people as possible in as-small-an-amount of time as possible. 1-3 people in 1-5 days with total freedom. The aim is not to come up with the end product. The aim is to:

    • create something manifest to have a conversation around
    • to provide initial material for user research that can flush out systemic issues
    • show the future
    • get people excited
    • expose gaps in knowledge
    • show how some hard problems might be solved
    • show the possibilities of current technology Make it as real as possible - put it online, make it send emails, demonstrate basic validation and use real data.

    Make it as broad as possible and resist the temptation to do a thin slice - start with the assumption of a single product or service, and set out to show the edges of it.

    Think hard about what you call it and how you describe it - avoid existing terminology or product/service names, people will try and map them onto the existing universe.

    9) Get a prototype in front of real users.

    Do not focus on testing the details of the interface or design - you won’t have got this right in a few days and your team will have time to iterate on that in the future.

    Early in a project, getting a prototype in front of users is primarily a tool to help the team understand the problem space, to spot systemic issues, and to just get to know users of the service better.

    10) Throw your prototype away.

    Throw the prototype away. It’s a learning exercise, not a product.

    ∞

    Notes - elements and self hosting

    ∞

    Where are the dedicated writing devices?

    Photo of an AlphaSmark keyboard For some reason, I seem to be thinking a lot about input at the moment.

    Something specifically that feels lacking - dedicated, internet enabled, writing devices.

    A reverse Kindle.

    How long before you can buy a Ghost or Wordpress device that is just a keyboard, small display and a big publish button? Will they be open, or a new way people get locked into a platform like Medium?

    The image above is of an [AlphaSmart Neo])(https://en.m.wikipedia.org/wiki/Neo_(keyboard)) - a discontinued note taking tool (Image (cc) tdhedengren). Something about that size, with dedicated, tightly bound, software UI would do it. Maybe with some mild built in nagging?

    I think I’m going to try and make one.

    ∞

    Cards

    Photo of question cards for a digital product

    • Who has done this before?
    • Who are your users?
    • What are their needs?
    • What is the right metaphor?
    • What tools do you need as a team?
    • What does the law say?
    • What new technology means you can solve the problem better?
    • How will you test the concept quickly?
    • Can you draw it?
    ∞

    Cucumber tests for regulatory data?

    This is a write up of an idea that came out of the Environment Agency hackday.

    How do we know software is working?

    We can run the software and look out for bugs. For an open-source project, we can inspect the code.

    We can also write and run automated tests against the software, so if it’s broken we know. Something like this:

    GIVEN a user is logged in
    WHEN they click on the 'my account' link
    THEN they can view their billing history

    That example is written in a format called Cucumber or Gerkin syntax. It is designed to both be readable, and to be written by, a non-technical person, but can be run automatically by a machine.

    How about a scientific experiment? How is that verified?

    Since the 17th century, it’s been via the publication of the results, along with a description of how to replicate the experiment, in a peer reviewed journal.

    Increasingly that needs to include any source code used to run the experiment.

    Finally, what about regulatory authorities? How does society verify that regulations are being met? How do we check for breaches?

    The relevant authority probably publish reports listing any breaches of regulations. They may also publish raw open data to show that in a transparent way.

    The Environment Agency, for example, publish data on pollution incidents, ground water abstraction and water quality.

    So we could look through that open data, and manually check it against the various regulations, legislation and policies.

    But what if we applied software testing principles to regulatory data and wrote automated tests to show up and breaches of regulations? Tests that were understandable and can be run by machines.

    They might look like this:

    GIVEN there is a release of Sulphur Dioxide from a power station
    WHEN the concentration of Sulphur Dioxide should not be greater than 40 ppm
    THEN there has been a breach of regulation E209

    Or this:

    GIVEN a company with license R409
    WHEN it abstracts > 100L in a 30 day period
    THEN there has been a breach of license R409

    Regulatory bodies could start publishing tests like these alongside the open data they release to demonstrate how they are regulating by showing their workings.

    Other interested parties - campaign groups, charities, parliament - could review tests against legislation and run them against the data to independently verify that the regulatory body is doing its job.

    ∞

    Notes: 2034, OSM mapping, triangulation

    Programming Perl in 2034 by Charlie Stross is just brilliant - he covers what causes things to change, to stay the same and the reality distorting change the awaits us in the coming decades (and the place of programming languages in 100 years time). The whole thing is quotable, but this about sums it up:

    “we can reasonably assume that any object more durable than a bar of soap and with a retail value of over $5 probably has as much computing power as your laptop today”

    On Wednesday I went mapping Brixton Market with Open Streetmap London. I was aware of Field Papers from Stamen, but never actually used them. They are brilliantly simple in use. They must have applications beyond OSM. Maybe to help Farmers fill in their Common Agricultural Policy applications?

    Also on a geo-tip, I’ve been trying to remember all the things I’ve forgotten about coordinate and projection systems from university.

    The whole thing is simplish in concept, complex in implementation. eg OSGB (the British National Grid) covers Great Britain only, but may or may not also include a small rock 270 miles off Ireland;

    I also came across The Great Retriangulation of Great Britain 1935 - 1962. By the time the survey was complete improvements in measuring technology meant it was probably out by approximately 20 meters.

    ∞

    Local government

    Sarah Prag has written a great shopping list of things a ‘GDS for local government’ might need, and points out that some would be controversial.

    Part of the reason some might be controversial is because, I think, there are some seemingly contradictory problems that need addressing.

    Rather than offering my own view on what a ‘local GDS’ should be, I thought I’d have a go at stating what the I hard things are, in the hope it makes evaluating the shopping a bit easier.

    The hard things:

    • Boundaries don’t reflect the real world

      If you want to know where the nearest open library or swimming pool is right now, you probably need information from more than one authority.

      If another authority starts on the other side of the road - you still care about any planning applications.

    • Geography is core

      The information and services that local government provides are often inherently geographical in a way that central government is not.

      Publishing systems and services need that baking into them in a way I don’t think is widely understood, and lacking in parallels.

      The understanding of geography is often hyper-local, beyond the understanding of what a centrally managed gazetteer can convincingly do. It is in the heads of residents and local officials.

    • Democracy and power matter

      Local governments are independently elected to provide services, in a way that separate government departments are not.

      As citizens we have the power to remove local government if it is not providing adequate services. The boundaries matter in this context.

      Separately, from time to time local government disagrees with central government, very occasionally to the point of serious dispute. In rare events like these, who controls the publishing button might matter more than we think.

    • Information is distributed

      The person who knows the times that the park shuts is probably the person who locks them.

    • Understanding of the structure of government is patchy and inconsistent

      People don’t understand the full detail of the structure of government, and should not have to.

      What’s local, national, devolved district, county? But then that understanding is different between people too.

    • The same problem is being solved many times over

      Or, at least a set of very similar problems, are being solved by each local authority. Any that is just and obvious frustration and inefficiency.

    Answers?

    I don’t know exactly what the answer is, but it probably is useful to start thinking of some parallels beyond just GDS to try and get to the answer.

    Here’s a few that seem to jump out at me:

    • Wordpress.com and wordpress.org - host it yourself or pay to host centrally (or your own domain or theirs). Code is shared and there is a healthy market in plugins.
    • OpenStreetMap and Wikipedia - and open shared commons of structured information editable by many.
    • FixMyStreet.com and Open 311 allow a distributed model of reporting civic infrastructure issues via multiple websites and apps.
    ∞

    Timeless

    We went to see Goldie’s Timeless end-to-end at the Festival Hall as part of the Meltdown Festival on Saturday. Live drums, live vocals. Amazing.

    They could have got away with so little, but instead it was obviously brilliantly planned, executed and performed brilliantly. Including an obviously health and safety approved (there were goggles and extra safety glass - someone put the time in filling forms) smashing of glass into a miked-up steel rubbish bin. Details.

    Someone has put a video on up here: [youtu.be/cTNoBEvU9…

    ∞

    Anatomy of a project space

    Diagram showing how to layout a team product space

    Download larger version to print

    Checklist

    1. Team
    2. Team room *
    3. Sprint planning room (co-joined)*
    4. Fast Internet connection
    5. User needs
    6. Principles
    7. Drawing of service
    8. Sprint wall x 2 (A & B)
    9. Story wall
    10. Screens x 2+ (for demos / information radiators)
    11. Email group
    12. Git repository
    13. IRC/chat room
    14. Wiki/note-sharing

    * Both with whiteboard walls

    ∞

    Notes: manuals, homomorphic encryption, lazy database

    Manuals (XKCD) and manuals (VW Beetle).

    Time to start understanding more than just the superficial about cryptography: http://en.wikipedia.org/wiki/Homomorphic_encryption

    Databases for lazy people

    ∞

    Input

    5 tiles is a brilliant example of designing from 1st principles.

    It is an android keyboard, designed specifically for touch-screens to keep the screen free for content. I’m slowly beginning to pick it up.

    I guess it’s similar to the sort of one -handed keyboards used by divers.

    It is a very different proposition from Google’s keyboard or Swiftkey which try and learn about you and predict what you are typing using your data.

    Instead it is asking you to invest time in learning a new system that allows a new freedom - more screen size (or the ability to type underwater for the diving analogy).

    I’ve also been using duckduckgo as default search engine for a couple of weeks as primary search engine on mobile and laptop.

    It stands up pretty well, but the best feature is !bang which builds commands to search other websites, like StackOverflow or Google Maps directly, directly into the core search. URLs as interface.

    In use, it feels similar to the sort of commands you find in vim and other text editors.

    I have a hunch that more alternative/complex input methods are going to start to become naturalised in more mainstream UI.

    ∞

    Moving from Gmail

    I finally got around to moving my email from Gmail to Fastmail. It’s been churning away moving over 8 years worth of emails for over 24 hours now.

    First, that meant sorting out my domain name. It was with namesco, who don’t support two-factor auth which no longer feels like an acceptable risk for something that has defacto access to your email.

    I moved it to iwantmyname.com. All very easy.

    Since they have one-click DNS setup for Ghost and github pages, I figured I may as well sort out my blog whilst I was at it.

    I culled my old one when the wordpress/ubuntu installs went horribly out of date, and never got around to sorting it out.

    So I now have blog.memespring.co.uk.

    They also make it simple to point a domain at github pages, so I figured I should fix the broken links I created to random talks / downloads etc.

    I’ve started to rescue old content from a mix of backups and archive.org at www.memespring.co.uk. Mostly slide decks for now, including this one from a 2006 event that I seem to remember Francis signed me up to talk at without asking me (I had never did any public speaking). Glad he did.

    I also added the video of the talk I did last year at Opentech which, listening to it now, lays out some of the early thinking behind habitat.

    ∞

    Notes: Capital Ring, habitat

    Completed the Capital Ring. Last 3 stages were a bit epic - about 19 miles in one day. Nearly walked into a deer.

    Deer in Richmond Park

    The Capital Ring is well worth the effort, but there’s a total lack of good online information about it. It’s crying out for a dedicated wiki of tips, being able to link to each stage, open GPX tracks.

    Off work this week, mostly working on habitat. I now have a working example client for posting location data, and for editing scenarios.

    Scenario client

    Both are written in Backbone.js, which I still haven’t fully got my head around.

    I ended up slightly hacking the oAuth workflow - since the habitat server is self hosted, the idea of issuing client ids, then adding those to the client, then giving permission is a bit odd. So, for now at least, the clients can choose their own.

    ∞

    Notes: 5 - 9th May 2014

    Walked stages 9 and 8 of the Capital Ring South Kenton to Osterly (3 more to go).

    Final show and tell of the Land Registry concept.

    More work on habitat - a personal, programable datastore (or that’s what it is untill I have a better desceiption). I got oAuth working using Flask oAuthLib. So you can now allow clients types of access to specific resources.

    Julian was down from Liverpool, so took him to visit South London Makerspace.

    Saw Mountain of Love (Eddie & Piers, formerly of Alabama 3) at Jamm.

← Newer Posts