RE: [backstage] Web2.0 - tennets, rules, development philosophy... I'd love you to give us some feedback

Mon, 17 Jul 2006 02:48:10 -0700

Title: Web2.0 - tennets, rules, development philosophy... I'd love you to give us some feedback
Firstly, the list seems fairly comprehensive and easy to read.
Secondly, apologies if there are obvious answers to this email, i'm new...
 
How come REST API gets mentioned, but ajax doesn't? 
 
I know ajax is an overused buzzword at the moment, but it is unavoidably crucial to the web2.0 push.   
Specifically in closing the gap with desktop applications in terms of application richness / responsiveness.
 
Also, although APIs and services are mentioned, perhaps this could be accented more?
The move to a service-layer based world can be a substancial paradigm shift.

-dan


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim Plowright
Sent: 14 July 2006 17:09
To: backstage@lists.bbc.co.uk
Subject: [backstage] Web2.0 - tennets, rules, development philosophy... I'd love you to give us some feedback

Hi all

As threatened, here it is…I'm part of a project internally that is looking at what the BBC does on the web, and how that should change over the next 3 years. As part of this, Tom Loosemore, grand paterfamilias of this list, has asked me to come up with some 'rules of the road for web2 sites'. Nice tight brief there, you'll appreciate.

So, I have a kind of a list of philosophical tennets - ways that code and design and data and content and whatnot should behave when playing nice on the internet. I'd be really interested to hear what everyone here thinks. Am I missing things? Obviously, I'm an editorial/management type, so some of this might be barmy. But.. What do you think? Have I missed anything vital about ways of making sites that play nicely on the web, and benefit the whole internet more than the organisation? That are, to nick a popular little motto, 'Not Evil'?

I'd really appreciate the thinking of you lot here. List follows the sig…. Let me know if any of the buzzwords are incomprehensible; I've stolen the categories from http://alistapart.com/topics/ because they seemed to make sense.

Kim
Kim Plowright  |  Snr. Producer, New Product Development
BBC Interactive Drama and Entertainment | MC1D6, BBC Media Village, 201 Wood Lane, London, W12 7TQ


Rules of the Road for web2.0 sites: Data, Metadata, Interface
Code

    Client Side

    • Semantic Mark-up
    • Elegant, simple solutions
    • Technologies used appropriately
      • e.g.. Flash elements on pages, not flash pages
      • Flash content should be sub-addressable?
    • Pages Structured for Machine Friendliness
    • Standardised naming for page objects that are reflected in CSS class names
    • Shared libraries / widgets / functionality across all sites
    • Degrades gracefully
    • No popups, ever

    Links and Linking

·       Permalinks for all valuable content, at a first-order-object level
·       Not to an index
·       URIs to ideally be under 72 characters

    1       URIs to be human meaningful - the user can extract information from the link

·       Hence Google can extract value from the link

          1       Truncating a URL takes you to a valid destination

·       Deep link externally. Encourage deep linking internally
·       Growth in incoming links as a measure of success / quality
·       Reflect linking activity on pages
·       But with sufficient spam filtering

    Accessibility

    • Build to degrade
    • Build for accessibility

    Common Engines

·       APIs
·       REST for Quick, light and elegant

          1       SOAP for the heavy corporate lifting
          2       Any new system developed to have a useful API

·       A componentised toolkit
·       Open Sourced wherever possible
·       technologies used appropriately

    1       Standardised Naming Conventions
    2       Test Early, Test Often, Test Thoroughly
    3       Use available technology whenever possible - don't reinvent the wheel.

·       Partner externally
·       All data available in machine readable format to other systems
Content

    UX

    • Accessibility
    • Aggregation
    • Personalisation
    • Richness
    • Appropriateness for platform
    • Appropriateness for mode of consumption
    • Graceful degrading
    • Annotatable
    • Shareable
    • Read/Write
    • Consistent functions and Labelling

    Appropriate to the medium

    • Written for the web
    • Produced for lean-forward consumption

    Trust and Promise

    • Value community contribution as much as your own
    • value should flow equally in both directions
    • Privacy respected
    • “You own your data. Full transparency.”

    Local, British

    • BBC Content is localisable
    • Reflecting the best of the web with a British perspective

Design

    • User centred design
    • Appropriate to content
    • Appropriate to audience

Process

    • Agile / Sprint / Responsive development methodologies

User Science

    IA

·       Nimble Data and Information
·       Open Standards
·       Every list as RSS

        1       Every page as RDF
        2       Every relationship as FOAF

·       Contribute to making new open standards
·       e.g.. TV Anytime
·       Data and Content Object Modelling
·       Common BBC data format to include extensible but controlled vocabularies (subject, people, location, date)
·       All data accessible in machine readable format by all other BBC systems

          1       All data accessible in machine readable format by our users (as much as poss)

·       Metadata

    Usability

    • Test for usability
    • Remember that you are not your audience; not everyone spends all day in front of the internets

    Accessibility

    • At the heart of everything, as good practice flows from accessible sites

Culture
Simply adopting Web 2.0 technologies does not make you a Web 2.0 organisation.  This is about a fundamental shift in philosophy

    • # Services, not packaged software, with cost-effective scalability
    • # Control over unique, hard-to-recreate data sources that get richer as more people use them
    • # Trusting users as co-developers
    • # Harnessing collective intelligence
    • # Leveraging the long tail through customer self-service
    • # Software above the level of a single device
    • # Lightweight user interfaces, development models, AND business models

Beta releases and continual small improvements
Clear Information paths internally, open discussion externally
User Centred Design
Editorial / Legal / Commercial policy



Reply via email to