Notes by Southwest: Notes from 3/11/08

Notes from sessions attended on 3/11/08 at South by Southwest.

---

“Content Management System Roundup”

Just the Gist

Comparison between:

• Sharepoint
• Drupal
• Expression Engine
• Collage (End-of-life)

George DeMet,
Owner,
Palantir.net

Jeff Eaton,
Lullabot

Tiffany Farriss,
President,
Palantir.net

Mike Essl,
Owner/Operator,
mike.essl.com

Matthew McDermott,
Principal Consultant,
Catapult Systems

View Notes

• Sharepoint (George DeMet - MS Sharepoint MVP)
• Full office suite allows for intranet and internet connection
• “Master page” + “Page layouts”
• Sharepoint designer
• Authoring view - DHMTL menus with options (when viewing pages)
• Workflow process and approvals built into system
• Branching built in for design variations and future changes (also versioning)
• Searching is included into the system
• Thesaurus and relevance ranking
• XSL + XML compliant
• “variations” - usually for multilingual sites
• “My Site” for intranet users
• Nav + breadcrumb
• Drupal - Jeff Eaton
• Built by the people who use it
• Hobbyists, businesses, volunteers, Belgians
• Fast Company, many other major companies
• Blogs, magazine sites, Terminus 1525 (artists community),
• LifeTime TV
• Pete Droge - all Flash content, mtv.co.uk, The Onion
• End Poverty, Inc. Magazine, U.S. Magazine, DC Comics “Zuda”, Pop Sugar, Interfacultair, Sony Music Box
• Around 3,000 plugins
• Theme > Views of Content > Content > Users > Modules and Drupal Core
• Users all have roles - designed to accommodate a large number of users
• Blog post - can filter by user
• Theme layer - generates all xml, html, mobile
• Can have all mobile pages
• Default Drupal site is very basic, functionality is added on via customization and plugin installation
• Great at:
• user-generated content
• Many kinds of content
• Communication
• Versioned content
• Other sites:
• Daughtry (Sony BMG)
• Artist interaction with community
• Multiple sites can be run from the same core
• Sony contributing back to project
• Expression Engine - Mike Essl
• “Me and Mr. T” - no custom PHP
• Archive, error, xhtml, css-compliant
• All fields on site
• Invisible NYC
• Material research - site coded in one day
• Evolution of CMS choices - Art Institute, Chicago
• Museum side and school side (2 sides to site)
• Round 1 (Custom PHP)
• Dreamweaver + CMS
• Good: quickly created and running, discrete scope, targeted, simple
• Bad: Navigation, difficult to extend, support (interim solution - rarely interim)
• Round 2 (Serena Collage)
• Nice master page structure
• Breadcrumbs
• “Contribution layouts”
• Good: Master pages, workflow, version control, training contributors, breadcrumbs, links as assets, deployment
• Bad: Expensive, slow performance, not mac friendly, navigation, training devs, interdepartmental, no support - dynamic, end-of-life product
• Rounds 3 (Drupal)
• Indianapolis Museum of Art
• Drupal - JQuery integration
• Can customize skin through interface
  
• Powerful templating
• Remote data
• User management
• JQuery integration
• Q+A
• Drupal - created an install profile to make new installs easier
• Actions and workflow - control access and approval (built into Sharepoint)

---

“Creative Collaboration: Building Web Apps Together”

Just the Gist

• Make sure that developers and designers are talking early in the process
• It helps for the designer to sit in the same area as the developers
• Team members need to be multi-talented in today’s environment

Paul Hammond,
Flickr

Simon Willison

George Oates,
Lead Designer,
Flickr

Matt Biddulph,
CTO,
Dopplr

Dave Shea,
mezzoblue.com

View Notes

• Dopplr
• About 1 year old, 4 people
• Ships several times per day
• Very collaborative
• “Technical wife and design husband”
• All active features can be switched on and off in dashboard
• Live testing = sculpting, not painting
• Simon Willison
• Used to work at Lawrence Journal-World
• Local paper in small town in Kansas
• 2 devs, 1 designer (css + html engineer), bunch of editorial staff
• The work at Lawrence Journal-World grew into the Django framework
• Parallel Workflow
• Devs design the underlying data model
• Automated admin interface allows content producers to start entering data
• Devs building the logic for the customer-facing pages
• Today...
• With apps, underlying data is not as consistent
• Continuing collaboration with a designer is essential right from the start
• Dave Shea - Mezzoblue
• Client design work, designer who codes
• Independent
• George Oates
• Flickr.com, over 2.3 million photos
• Paper and whiteboard
• Over 20 million photos
• Core dev team grown from 3 (5) to 16 (40)
• Supporting cast of over 100 people
• Still try to release early/often, but is difficult with more people and a larger organization

Decision-makers

• Everyone responds well to seeing a design mockup
• Collaboration between the roles - don’t leave out
• Flipside, “skin this”
• Make sure both are involved early
• Sit in the same room
• The top-down stuff can cause a top-down breakdown
• Prototyping very useful, especially with live data
• When you build prototypes (in company)
• Depends on skill-set of team

Job Roles

• Need to be multi-talented
• Most productive involve small teams of generalists
• Shared understanding of produce - voice of product
• Devs can see weird little use cases, errors, etc
• Especially important for independent to generalize
• Larger teams have a harder time making decisions
• Sometimes there isn’t as much overlap as there should be
• Process is an antidote for stupid people
• Shea: Contracts explicitly set out a design process
  • Enforced only if it’s taking too long
• Humans don’t respond well to anarchy but also revolt against overly pressuring red tape
• Internationalization can invite more problems
• Designing for blank slate, zero data, data constraints, are important when designers are working with live data
• Learning svn is a very good idea

How can devs and designers communicate more effectively?

• Client-side vs. back-end developers - need to have people that are focused on each
• Abstractions are a little to tough to talk about in the beginning
• Agile change management and request systems
• Quickly make suggestions and rebuttal - smarty for PHP
• Bugs and design decisions
• Differences between team structure and personalities
• The design quality of the prototypes should reflect the level of completion
• Put a css class on the pieces that are not finished
• Mentoring is incredibly important
• Agile really relies on client being present
• Client-side dev - at least slice up images

---

“Taking Over the World: the Flickr Way”

Just the Gist

• Localization can be made less painful, but requires a lot of good planning
• Community and professional translation methods can be leveraged for community-centered sites
• The business must also be localized, how will you provide support and allow feedback for other languages?
• Always use UTF-8 and plan the system for possible future localization (keep internationalization as part of the creation process)

Simon Batistoni,
Flickr/Yahoo! Inc

View Notes

• Flickr engineering team
  • Launched June 12th, 2007 -the localization took 7 months for 7 countries
  • Emphasis on language over locale (not everyone in the U.S. speaks English, and that's true for every country in the world - every citizen of a country does not necessarily speak in the official language.)
  • Good set of localization tools when you can use it in a wide range
  • Too many words/legacy code
  • UTF-8 was already being used, helped - time zones
• Hugely passionate community
• Usually people aren’t as emotionally invested in most sites
• Flickr-people feel more passionately
• Other challenge - owned by a big company. The purchase by Yahoo! gives Flickr a lot of resources to work with, but it also comes with more large company issues to deal with.
• Introduces other strains and constraints
• Internationalization vs. localization (i18n vs 110n)

Internationalization

• What you do to make the site ready for localization
• Make sure to deal with time properly
  • Character data/sets
  • Community data/sets
  • Community interaction - bugs, reports, etc
• Content classification - different countries have different value systems, especially an important distinction for media. What is okay in the U.S. is not okay in some other countries, and vice versa.
• Payment systems
• When is the right time? Doesn’t really matter, but should worry about it from day one.
• It’s only okay to not internationalize a system unless you’re absolutely sure that it will not be localized (extremely rare)

Localization

• Not just starting, where does it make sense to begin the process?
• Language-switch
• Legal review - large or small company - legal landscape in other countries
• Ex: YouTube in Pakistan (keeps getting shut off)
• Issues can impact you in a big way
• Staffing - need very different structure - need to be able to take things like bug reports, and provide customer customer care. If it needs to be translated for product team to respond, how does that happen?
  • All information must get routed tothe right place to provide the right sort of response
• Flickr did a tour of all the countries that they were localizing for
  • Ex: Found that Korea didn’t like white layout - too much whitespace
  • Have not yet addressed other versions of template for issues such as this
• Don’t Rush!
• Focus on building a really good product first
• Better to do it late than horribly, to enter a market and get a bad reputation is much harder than to launch when ready

Be prepared

• Make sure you know where all the text strings are
• Image tags with titles and acts
• HTML alone is not enough
• Some people use keys {sentence_replace_confirm}
  • Downside: debugging templates becomes very difficult with so much meaningless data on the page
  • Slows down entire process
• Trans Jaxxx - the tool Flickr built for text strings uses a similar marker, but is much easier and semantic to view - just adds little tags like <!!>Text for translation</!!>
• Also work in title tags and iamges
• Attributed such as
  • <!! esc=”squat”>TEXT</!!> (escape the string)
  • <!! dev=”replace”> (replace the string)
  • <!! note=”not goes here”> (note for the string)
• Can be working on 5 or 6 things at one time (features)
• preg_match_all
• W3C has internationalization system can all be together
  quite complicated
  • http://www.w3.org/International/its/

Say no to concatenation, can cause a lot of problems for the system

• My {$beverage} brings all the {$gendered-people} to the yard
• BAD! = FRENCH
• More code than there should be
• <!!>{$username} added you as a contact</!!}

Dates, times, numbers

• Give choice of time zone, 24 hour can also be worthwhile
• Important to set locales
• German: top (1,000) is actually (1.000)
  • www.vladdy.net/demos/printf.html

Encoding

• Use UTF-8, always, just do it
• Matches ASCII characters
• Most compact byte representation

Design

• German is awful for line length
• Must be flexible
• Fluid too a degree, has to be able to expand a bit (40-50% - but sometimes too much)
• When you use images with text in them, need to create them each time - drawback, but makes a decision

Taking The Plunge

• Established growth
  • Growth potential
  • Usage possibility, or growth market
• Potential headaches
  • Localize somewhere, need support
  • If not, a web site with no way to contact us - highly discouraging to users
  • Content - legal, cultural issues
• How much money do you have?
• Have to worry about translation
• Translation management tools
• (http://en.wikipedia.org/wiki/Translation_memory)
• Trans Jaxxx - internally (Flickr)-built translation tool
• Text units have red boxes around them (using the tool)
  • QA people can click on to edit the text
• Community-powered Translation
  • Free, or at least, cheap
  • Broader demand-driven translation
  • Community ownership of content and process
  • Downside: moderation and QA can be difficult
    • Community or professional for review? Can do it either way, but need to choose early. Some sites are using a mix, this is all easier to do if the site already has a solid user base. English-speakers already using the site are often motivated to help localize the site if they have ownership. in it. The biggest successes have so far been community-based sites, which makes sense because there is a source of motivation for “free work” to be provided.
  • Community-only translation does not address the support issue of providing the same level of support to each country if you are only an English-speaking organization.
  • Also doesn’t allow for secret launches (everybody knows you’re doing it)
  • Examples: Live Journal, Xanga, Facebook, Google
    • Facebook dumped in text from Babblefish and then let the community correct the text
• Professional Translation
  • Banks of translators, all over the world
  • Is expensive
  • Hard to capture right tone, pros don’t usually care about keeping the tone or personality of the site correct, more about volume
• Deploy - Flickr deploys between 5 and 10 times per day
• Pre-bake all templates (PHP + Smarty)

Legal/Policy

• Get some advice from someone who knows, which probably means someone from the region that you are localizing in
• Cultural considerations

Foster A Single Community

• Tear down the barriers where you can
• Groups - allow translation of groups by users
• Other help is geographical stuff
• Visual means where language doesn’t matter - very helpful
• Want to make localization seem trivial
• Google makes assumptions based on IP, but that has a lot of drawbacks
• Even in US, there are plenty of other languages besides US
• Flickr uses a multi-stage “flitering” to determine what language to display first:
  • Cookies for return visits, preferences on other Yahoo! properties
  • Look at where they came from (Ex: if the traffic came from a French-speaking site, chances are that they speak French)
  • Flickr also use IP location, never heard complaints
• hitherto.net/talks, simon@hitherto.net

Question & Answer

• Using .fr for anything?
  • No, but the switching is not good right now
• Combine community and pro translation?
  • Pro as QA - professional translators provide the quality assurance and make sure that each translation is actually saying the correct thing for each text string
  • Community as work - community provides the text translations
  • “Draft and Official” versions of site - “draft” before it goes into review and becomes “official” text
• How does Flickr handle support issues for localized versions?
  • Have support agency to filter incoming reports
  • Also have employees to do forums
  • It needs a human being behind it, can’t just throw a product out with a language and no one behind it
• Release Transjaxxx (the custom internal tool that was written by Flickr)?
  • Would like to, but nothing is solid
  • The downside of most translation software is that it tends to be desktop-based