Dojo Developer Day #2

These are the notes from the second Dojo Developer Day (Jan 12-13, 2007 at AOL in California).

Opening Comments: Dylan & Alex

See the slideshow

Vision, purpose, project goals, strategy

• what should we be when we grow up?
  • turbo ajax:
    • don't want to remove things
    • increase modularity
    • tool to support development process
    • trim src/ directory on per-release basis
    • api reference helps
    • clients want fast load times, trim features to get there
    • the challenge is to communicate "what it is"
    • OOTB is different from real-world needs
    • server-side hinting is a huge boon to performance
    • fast first, easy later?
      • ease of use as an add on
    • their own shims to handle back-compat
      
  • dylan:
    • separate projects/repos?
    • we can't tell others that they're wrong
    • website sucks
    • separate project at the Foundation for server-side stubs?
    • css pre-processor would be a huge win
    • demos not optimized for performance
    • style guide does not cover the in-the-large problems
      
  • brad:
    • "what do we want that inital experience to feel like?"
    • what are the top 10 ajax needs?
    • "guerrilla usability"
      • for APIs, not just UIs
      • can developer accomplish task after quick breifing
    • configuration vs. convention
    • google search leads to stale docs
    • mark old docs as obselete
    • easy and fast not different necessarily 
    • common question data is available from the dojo-interest archives
    • is the "web designer" a red herring?
    • has seen OSS projects die from back-compat
    • get Parallels
      
  • owen:
    • what are our criteria for success?
    • pick 5 personas
    • metrics for load times/complexity
    • task-driven design
    • naming
      • gfx vs. lfx
      • clarity more important than brevity
      • too many API concepts
    • not providing server API straw men is hurting us
    • lots of time spent in discovery
    • widget system should be more well layered
    • designer solution may not be part of the system
  • alex:
    • "how do you register an external namespace?"
    • < 20% can do it
    • smart dev took 3 hours
    • hard cuts vs. back compat
  • dewitt:
    • code is the only reliable docs today
      • code is hard to understand because of back compat
  • amit:
    • point of dojo is to activate the web
      • static -> dynamic
    • dojo success should drive browser features
      • millions of dev users
    • must become equal to a professional project
      
  • gavin:
    • who are our users? Really?
      
  • greg:
    • jmaki already provides sever-side hinting in the way that's been proposed
  • karl:
    • 50% of traffic is n00bs
    • Dojo-interest
      • questions on "how to update content pane?", "why can't I append stuff to a content pane?", "back compat?"
• why is dojo hard?
  • gavin: higher powered, new concepts, more overhead
  • brad:
    
    • too much surface area
      
    • You have to bite off the whole thing
      
    • Too hard to grab a single thing
    • common stuff is hard
  • owen: scope is so large, and lack of consistency. No narrative voice.
  • bob: download is huge, lack of education process. "huge, but..."
    
  • joyce: people suffer w/ other tools, but don't complain
  • greg: perception gets set
  • chris: comedy of errors. task-oriented introductions are lacking. not targeted. prototype vs. dojo comparison.
  • amit: wasn't developed for people who aren't us. 95% is explaining and cutting things out
  • karl: docs
  • dylan: we err on the side of tech, not users
• Who aren't our users?
  • bill: simple/advanced
  • dylan: app devs/html+css
  • gaving: users shouldn't be one-offers
    • dylan: it's what we're already good at
  • owen:
    
    • prototype, scriptaculous in a niche, let it be
    • should focus on advanced users
  • brad:
    • appreciative inquiry
      • what are we good at?
      • how do we expand it?
  • becky:
    • marketing
  • bill:
    
    • pretty happy with how things are now
  • alex: digestability vs. architecture
• • joyce:
    • competition isn't a factor
    • significant pain for every change
    • confidence in what we are, and understand our niche
    • devs are saying that they hate it for the first 3 widgets, religious conversion afterward
    • get people over the "3 widget hump"
    • not as competitive for one-off's, and that's OK
  • korentag:
    • just ported major app from 0.3.0 to 0.4.1, major pain
    • as we make clean breaks, they need to be well documented
    • there's enough in Dojo to keep it's value
  • chris b:
    • started w/ kitchen sink, got lost
    • work from trunk...always have everything
    • no stock builds, force folks to build on their own
  • dustin:
    • provide source packages
  • chrism:
    • gotta get to SVN to get to build system
    • wants small package just for the build scripts
  • amit:
    • small core
    • utilities
    • widgets
    • then from then, use web-based build
    • core must appeal to broadest audience, "dojo.ajax core", target teaching to this
• RESOLVED:
  • create summary and vote tomorrow

Releases

0.4.2 release in a few weeks

Just a few bug fixes

0.9 release goals

non backwards compatible (changes w/out deprecation)

widgetCore project (rename Menu2 to Menu) (see below)

dojox project (see below)

tundra theme on all widgets

maybe some of alex's performance changes

dnd refactor?

tree api changes

dojo.data?

1.0 goals

release in june/july

Process changes

• commit hook
  • enforces ticket reference
  • for trunk
  • owner review for critical modules
    • widgets
    • bootstrap
    • others?
      
• owen: no checkin w/o tests?
  
• gavin: separate thinger for experimental
• svnmerge.py
  

Demos

jMaki - Greg Murray
    This is a server side framework for dojo.

Lightstreamer + Dojo integration - Dylan/SitePen

WhereToLive - cool real estate demo - Chris Barber

Accessibility - Becky
    She showed screen reader, and high-contrast mode support (where CSS background-images are disabled)

Documentation - Owen

Carla is finishing at the end of the month; need someone to take on the project.

Dead tree book: If anyone feels like writing a book on dojo Alex can hook you up with a publisher.

For new features, you need to file a ticket with a use case explained; that becomes the documentation.

Proposal that  a feature can't be marked non-experimental until the documentation is complete.

Testing

We talked a little bit about testing.

Widget discussion

We talked a lot about characteristics of the current system, how it evolved and what would be ideal.  Different things are (obviously) more important to different people.  (See the list below).

Alex brought up the concept of thinking about restricting all of the degrees of freedom that we currently allow:
    HTML vs SVG/VML
    Parser vs Prodedural
    Complete CSS flexibility vs taking a step in the ground on class names, etc
    Fewer code paths
    Behavior vs template instantiation
    Flexibility in options per widget

We listed the following characteristics of the current system/an optimal system.  Everyone who was interested then was given 5 "votes" so we could try to get a straw poll of what was characteristics were most important to the folks in the room.  The items are listed in order of the number of votes received.  Note that this is NOT intended to say "we'll support this and not this" but rather to get a sense of which lines we should optimize on.

    Votes   Item
    -----  ----------------------------------------------------
    16      Cheap to instantiate programmatically
    11      Modularity - get just what you need
    9        Data binding
    7        Accessibility
    7        CSS themeability/skins
    6        Markup/script duality/ability
    6        Attach points (dojoAttachPoint)
    6        Nested/composite widgets
    5        Internationalization
    5        Easy to learn and understand
    4        Event attachment
    2        Template system
    1        Cheap to instantiate from markup
    1        Code footprint/size
    1        Basic API such as show/hide
    1        Promotional ability (take an existing node and promote to a widget)
    0        Dynamic templates/macros
    0        Auto-require based on in-page widget specification
    0        Fascades (embedding widget x in dropdown, in popup, in page)
   

Tundra Theme - Torrey

See the mockup

Torrey also showed Tundra button.

All styling will be done via CSS, with no image tags (except for foreground images).

HTML templates will be simplified to just support Tundra.

Single CSS file?

Performance - Alex

See the slideshow

dojo.data - Brian

Saw demo of what we have now.

Summer of Code 2007 - Brian?

Reviewed last year.   Looking for volunteers for 2007

• work for January-March -- SummerOfCode
  
  • pick 2 admins
  • sign up mentors
  • start student outreach
  • post timeline

Separating Dojo Into Separate Projects

We discussed splitting dojo into separate projects, and also a community repository.

Big companies like IBM and Sun have trouble using code from a general repository unless the licensing is clear.

Proposal to have a DojoX? project hosted by the Dojo foundation, with licensing & CLA identical to Dojo, but with a different committer list.  (All Dojo people are dojox committers but not vice-versa)

Maybe eventually have another tier with any licensing people want.

"Gallery" idea, a portal that points to everything.


Discussion about pros/cons:

• Ways to solve the breadth/introducability duality
  • split it up
  • docment it and ship what we have
  • constrain the surface area
  • coarse split
    • core vs. widgets?
      
  • core widget set + non-core
    • separate project
  • • sanction one of them, eject the others
• Straw man:  See: 3D2BreadthProposals
  
  • coarse split
    • widgets
    • core
    • trim/strip core
    • distribute separately
    • break compat
      
  • dylan:
    
    • artificial split, what's done, what's not.
      
    • tsars for cross-cutting concerns
    • widget infrastructure different than widgets
    • moo.fx has browser-based system for building
      
  • bill: allows competition between widget sets
  • owen: why not atomize? avoid duplication!
    
  • bryan: widgets broken out, not too much granularity
  • james: separation rule should be:
    • no owner for support and docs, it's out of core
    • many widgets not supported, not maintained
  • brad:
    
    • competitive analysis
    • how are we gonna leapfrog for user benefit
  • dustin:
    • leave what we've got, but new widgets in other system
    • testing a problem
    • widgets are used by people with different set of taste
  • tom:
    • karl's community idea could host things that might otherwise get trimmed

Quick vote results:

Core
-------------
Adapter Registry
Deferred
Debug/Profile (Infra)
Collections
Data (infra)
Date
Dnd
Dom
Event
Html
Io
String
Uri
Json
Lang
Lfx
Math
Regex
Rpc

Not Core
------------------------
Behavior
Calendar (iCal)
Charting (Engine)
Data (Impl)
Crypto
Docs (API Tool)
Flash
Gfx
Logging
Math
Selection
Storage
Vector Graphics
Undo
Uuid
XML
Validate
Non-Core widgets

Widgets-Core

Bill will "rule the widgets with an iron fist" (Alex's words), with Becky for A11Y and an IxD? person.    The widgets will be split into widget-core (probably a separate project) and dojox above.

See Bill's presentation.

Miscellanous

See also the proposals page

IE5.5 was desupported.