Web Directions North » Blog Archive » Web Apps

Web Apps - Developer to Designer

• Presentation by Georges Oates and Paul Hammond
• Introduction by Dan Rubin
• Website no more
  • it’s not about static web sites anymore
  • like Flickr, updated every second
  • web 2.0 is about people, engaging, very social space
  • requires stability in our platforms
  • collaboration and sharing, how are people mashing
• (a picture demonstrating a popular contact on flickr showing connections to other users)
• (another picture showing relationship between Flickr groups)
• “it’s the people that are instructing the machine about relationships” We’re making the structure

Data, data everywhere

• over 300 million photos on Flickr

Design for unknown context?

• can’t really use a persona to define how you’d use the system. we all take different path. how do you design for system that’s constantly changing? Allowing them to explore. The Flickr API has an abstraction that gives others the flexibility to mash it.
• (example of art exhibit where people would make up their own rules when playing with a “game space”)
• “there’s the poeple that do the interaction markup, and then there’s the people that do the hard stuff” ~ Cal Henderson
• PHP example
• HTML example (has image, font tag with comic sans)
• for the backend people, it’s about stability, security, performance.
• Google suggest is a nice interaction but how do you get the performance from the backend.
• Client side code can actually solve server side scaling issues (for example, Mac()Live was able to do twice the bandwidth during the keynote)
• CSS/HTMl separation - the presentation layer, the markup layer
• hard to separate them completely. inevitably changes to the HTML occur when making changes to a site design.
• “How Buildings Learn - what happens after they’re built”
• structure, skin, services, space plan(the walls), stuff - changes constantly; each layer depends only on the layer beneath it.
• URL - doesn’t change
• Content - changes all the time
• “The Elements of User Experience” ~ Jesse James Garrett
• strategy, scope, structure, skeleton, surface
• those diagrams don’t tell you how to do it.
• 3 teir: web server, Application server, database server
• View, Controller, Model
• Frontend and the Backend, how do we join the two together?
• How do we divide them up nicely?
• Trifle:
  • Sponge: Database, Jelly: Business Logic, Custard: Page Logic, Cream/Markup, Fruit: Presentation
• MySQL, PHP, HTML CSS / there’s a gap in the middle
• Templating language
• (example using {{ pagetitle }} demonstrating template language)
• can do conditional logic.
• Smarty
  • PHP based, Fast (templates are cached), awkward syntax
• XSLT, XML based
  • works with most programming languages
  • functional programming
  • verbose
  • eXSLT
• ERB
  • Used by Ruby on Rails
• Django, Liquid, TAL,…
• Improvised solutions - having a PHP logic only concerned wth page logic
• (similar to before but with Smarty in the middle)

Ajax

• add javascript, interfaces with the server via an API
• Get Raw data, for example JSON
• example Flickr examples returns in XML and JSON
• “Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” ~ Saarinen
• must have a common understanding, understand how you’re going to split up work. Must have these conversations before you start.
• backend developer / frontend developer and all the other team interactions. there needs to be more interactions between these people.
• Small teams of awesome people

A Case Study: Project “Adelaide”

(the remainder of this was captured by Dan Rubin)

• geotagging: dorky
• geobloggers.com (also, fairly dorky)
• “where on earth” - lots of data, but needed a way to present it
• constraints:
• “show location” - human-readable information (users may not drop photos on the exact location)
• search - how the map looks, limit of 4,000 results, pagination issues in the UI
• UI design of the maps - iteration of the markers used to identify photo locations
• markers needed to work on any map terrain
• some good ideas couldn’t be used because of performance limitations
• settled on using dots of various sizes to communicate the number of photos quickly
• UI example: place search - example shows multiple results for “paris”; maps UI borrowed mostly from Yahoo! maps
• example of the exploded view of the custom UI elements for the map - exploded view helped communicate George’s intended functionality of the elements to the developers
• dropping a photo - visual example given, along with supporting instruction of how it should behave
• in a small team, you don’t need to document how something will work, you can just talk about it and quickly sketch things out
• spending extra time to make search results more readable makes a big difference in the user’s experience
• over 1,000,000 geotagged images within 24 hours after release
• Paul to George: what’s changed since the Flickr geotagging launched? George: added lots of data, would like to remove pagination, looking into a heatmap-like interface
• data goodness? - there were issues that could not have been anticipated regarding the accuracy of the “where on earth?” data
• example given about a user from Germany who noticed inaccuracies that could not have been easily known otherwise - you need lots of eyes to find all these things. Key phrase from that user regarding how it *should* have been: “that’s what I would expect”
• Flickr API user agreement examples - “you shall” and “you shall not” (see presentation)
• if you are considering implementing an api, you must put gates in place - non-commercial api keys are available; give yourself the ability to turn keys on and off to prevent misuse/abuse of your system
• it’s not unreasonable to assume that a user isn’t aware that their photo can be accessed via the public api, so users must be able to opt-out
• multiple examples of api uses (see presentation)
• you can’t control what users actually *do* with a public api; you have to accept and embrace the ways users will display your data (good or bad)
• example: Flappr - flash interface for Flickr
• example: Flickr Tag Browser - built in Flash, allows you to browse using relationships between tags
• back to Paul
• when you open up an api, people will start doing things with your site, and you have to deal with that on some level - how much control you give, how much trust you are willing to give outside your team, particularly with the backend, load issues, etc.
• example: Yahoo! pipes - allow non-programmers to merge data from a wide range of sources (anything with an RSS feed, multiple Yahoo! sources, etc.).
• Audience question: wants to hear more about the design process, and how it’s all worked out within the team. George’s answer: things are worked out as they go, once a prototype has been created, they can get a sense of the load introduced, etc. Paul: some things just happen without thinking too much, others occur as a result of the development process, and at some point you just need to build something and release it, and then see where it goes. Sometimes the solutions to a design problem are on the backend, sometimes backend issues can be solved in the UI. George: when the team decides to prototype something, it generally becomes a feature.
• Audience question: what kind of approaches were taken with regards to api interoperability? Paul: it needs to be reciprocal. it’s a new area, and there are a lot of problems with opening user’s information to the public. Things like Microformats are helping.
• Audience question: thoughts on scope of ownership, etc., specifically regarding tag usage (listen to the podcast for the entire explanation). George: it’s a social issue to resolve, not programmatic. Something that has to be figured out as we go.
• Audience question (Jeremy Keith): regarding the issue of full, recursive access to data via an api, and responsibility that results from data appearing where users don’t want it (example: Jeremy’s custom UI for Flickr, in combination with Google spidering all recursive links to his contacts, results in angry emails to Jeremy from people asking that their photos be removed from his site, however they aren’t on his site nor under his control)
• Audience question: what are George’s thoughts about sharing code? e.g. what happens when Flickr wants to implement something that a user has created via the api? General answer: no one wants to rip off someone else’s work, sometimes they might hire a talented programmer with a great idea (already happened at Flickr)
• a few more audience questions, illegible (check the podcast)

Posted by Jonathan on 13/02/07 at 11:19 pm