- Revision
- 871
- Author
- mde
- Date
- 2006-07-21 13:48:08 -0700 (Fri, 21 Jul 2006)
Log Message
Updated Web UI slides. Also original work done to S5 template.
Modified Paths
- trunk/docs/oscon2006/cosmo.ppt
- trunk/docs/oscon2006/cosmoScooby/scooby1.html
- trunk/docs/oscon2006/cosmoScooby/ui/default/pretty.css
Added Paths
Diff
Modified: trunk/docs/oscon2006/cosmo.ppt
(Binary files differ)
Added: trunk/docs/oscon2006/cosmoScooby/images/sync_async.jpg
(Binary files differ)
Added: trunk/docs/oscon2006/cosmoScooby/images/ui_grab_detail2.jpg
(Binary files differ)
Modified: trunk/docs/oscon2006/cosmoScooby/scooby1.html (870 => 871)
--- trunk/docs/oscon2006/cosmoScooby/scooby1.html 2006-07-21 00:16:54 UTC (rev 870) +++ trunk/docs/oscon2006/cosmoScooby/scooby1.html 2006-07-21 20:48:08 UTC (rev 871) @@ -51,7 +51,8 @@ <h1>Guiding principles</h1> <ul> <li>A Web app, not a Web site</li> - <li>Cross-browser, Web standards</li> + <li>Standards-centric</li> + <li>Cross-browser</li> <li>Separating the UI from the data</li> </ul> @@ -61,11 +62,11 @@ </div> <div class="slide"> + <image src="" alt="" + style="display:block; width:581px; height:401px; float:right;"/> <h1>UI Overview</h1> - <image src="" width="581" height="401" alt="" - style="display:block; width:581px; height:401px; float:right;"/> <ul> - <li>Web Standards</li> + <li>Web standards</li> <li>Interactivity</li> <li>Skinnability</li> </ul> @@ -76,12 +77,11 @@ </div> <div class="slide"> - <h1>Breakdown: UI Elements, Current</h1> + <h1>UI Elements, Current</h1> <image src="" width="246" height="339" alt="" style="display:block; width:246px; height:339px; float:right;"/> + <div>Absolute-positioned DOM elements, primarily divs -- a bunch o' boxes.</div> <ul> - <li>DOM elements, primarily divs</li> - <li>Absolute positioning, pixel widths</li> <li>Benefit: resizing and drag-drop very straightforward</li> <li>Problem: recalculating / repositioning UI elements on window resize -- currently uses page reload @@ -94,22 +94,41 @@ </div> <div class="slide"> - <h1>Breakdown: UI Screenshot</h1> + <h1>UI Elements, Moving Forward</h1> + <div>Refactoring of UI code for better + separation of loading / rendering concerns</div> + <ul> + <li>Benefit: Will make it easier to size and place UI elements + when resizing window + </li> + <li>Challenge: Creating a design that's flexible + enough for the UI to evolve -- + including (later) non-calendar collections</li> + </ul> + + <div class="handout"> + [any material that should appear in print but not on the slide] + </div> +</div> + +<div class="slide"> + <h1>UI Layout, Screen Grab</h1> <image src="" width="719" height="420" alt="" style="display:block; width:719px; height:420px; margin:auto;"/> </div> <div class="slide"> - <h1>Breakdown: UI Elements, Moving Forward</h1> + <h1>Events, Current State</h1> + <div> + Global event listeners with a custom dispatch system -- two + basic types: + </div> + <image src="" alt="" + style="display:block; width:142px; height:304px; float:left; + padding-right:1.5em; padding-top:1em;"/> <ul> - <li>Significant refactoring of UI-specific code for better - separation of loading / rendering concerns</li> - <li>Benefit: Will make it easier to size and place UI elements - when resizing window - </li> - <li>Challenge: Creating a design which is flexible - enough to allow continued evolution of the - UI code, including (later) non-calendar collections</li> + <li>DOM-element <code>id</code> (regex-based, ex. event blocks)</li> + <li>Custom properties (ex. minical)</li> </ul> <div class="handout"> @@ -118,42 +137,45 @@ </div> <div class="slide"> - <h1>Breakdown: Events, Current State</h1> + <h1>Events, Current State: Benefits</h1> <ul> - <li>Primarily global event listeners with a dispatch system - that calls the appropriate code based on the id of the - manipulated elements.</li> - <li>Benefit: Single channel of event flow is easy to debug.</li> - <li>Benefit: Low memory footprint due to no creation of DOM-node - or handler references</li> - <li>Benefit: Less issues with loss of scope because events - are dispatched in window scope.</li> - <li>Problem: Brittleness. Overloading the id property - requires well-designed naming convention for elements, and - tricky regex parsing of ids to dispatch events properly. + <li>Single channel of event flow, easy to debug</li> + <li>Low memory footprint, less opportunity for leakage</li> + <li>Events dispatched in window context, less confusion + regarding scope</li> + </ul> + + <div class="handout"> + [any material that should appear in print but not on the slide] + </div> +</div> + +<div class="slide"> + <h1>Events, Current State: Problems</h1> + <ul> + <li>Brittleness -- (<code>id</code>/regex) + requires specific naming convention and tricky regex parsing </li> - <li>Problem: Unweildiness. Increasing UI complexity makes - global dispatch code grow unacceptably large</li> + <li>Unweildiness -- increasing UI complexity makes + dispatch code grow unacceptably large</li> </ul> <div class="handout"> [any material that should appear in print but not on the slide] </div> </div> + <div class="slide"> - <h1>Breakdown: Events, Moving Forward</h1> + <h1>Events, Moving Forward</h1> + <div>More of <code>dojo.event.connect</code> with 'topics'</div> <ul> - <li>Increased use of Dojo's event.connect and hitch with - 'topics' to assign event listeners programmatically</li> - <li>Benefit: Allows more decentralized pub/sub model of - communication between more decoupled components. This - means better facility to handle increasingly complicated - interactivity.</li> - <li>Challenge: Programmatic addition of event listeners can - make debugging very challenging -- no central 'clearing - house' for user input.</li> - <li>Challenge: More references to DOM nodes increases memory - usage and the potential for leaks. + <li>Benefit: Allows more decentralized pub/sub + communication, and more loosely coupled components</li> + <li>Challenge: Attaching listeners/handlers programmatically + makes debugging harder (where the #$*@ is that + coming from?)</li> + <li>Challenge: Trusting toolkit to handle DOM-refs and + memleak issues </li> </ul> @@ -163,15 +185,31 @@ </div> <div class="slide"> - <h1>Breakdown: Async. Code, Current State</h1> + <h1>Inevitable Async. Requests Graphic</h1> + <image src="" alt="" + style="display:block; width:510px; height:420px; margin:auto;"/> +</div> + +<div class="slide"> + <h1>Async. Code, Current State</h1> + <div>Loss-of-scope issues from callbacks solved with:</div> + <ul> + <li>Singletons</li> + <li>External registries with object/request IDs</li> + <li>Closures</li> + <li><code>Function.apply</code>/<code>Function.call</code></li> + </ul> + + <div class="handout"> + [any material that should appear in print but not on the slide] + </div> +</div> + +<div class="slide"> + <h1>Async. Code, Current State (Cont'd)</h1> <ul> - <li>Loss of scope issues from callbacks solved with: -<ul><li>Closures</li> -<li>External registries with object ids</li> -<li>Singletons</li> -<li>Function.apply/Function.call</li></ul> </li> - <li>Benefit: Well known solutions to a well known problem</li> + <li>Benefit: Well-known solutions to a well-known problem</li> <li>Problem: 'Patchwork' solution requires developer experience and understanding of why each approach is appropriate, and when</li> @@ -183,12 +221,13 @@ </div> <div class="slide"> - <h1>Breakdown: Async. Code, Moving Forward</h1> + <h1>Async. Code, Moving Forward</h1> + <div>More of <code>dojo.event.connect</code> and + <code>dojo.lang.hitch</code>.</div> <ul> - <li>Increased use of Dojo's event.connect and hitch.</li> - <li>Benefit: 'Just works.'</li> - <li>Challenge: Black-box approach can be confusing or - difficult to debug when something goes wrong.</li> + <li>Benefit: Just Works™</li> + <li>Challenge: black-box approach can be bad + when something goes wrong</li> </ul> <div class="handout"> @@ -197,25 +236,13 @@ </div> <div class="slide"> - <h1>Building a Large-Scale Ajax App</h1> + <h1>Large-Scale Ajax Apps: Challenges</h1> <ul> - <li>General Challenges</li> - <ul> - <li>Many software engineering techniques are migrating - to client-side app development as Web dev becomes more - ubiquitous and Ajax UIs become more sophisticated. -</li> - <li>What is the best way to apply these techniques, and - where? -</li> - <li>Two worlds collide: client-side and server-side devs.</li> - <ul> - <li> Front-end devs dealing with application engineering</li> - <li> Server-side devs dealing with weird client-side code</li> - </ul> + <li>Software engineering migrating out to the client</li> + <li>How and where to apply these techniques?</li> + <li>Two worlds collide: client-side and server-side devs</li> <li>_javascript_ grows up: it's not just for image rollovers</li> </ul> - </ul> <div class="handout"> [any material that should appear in print but not on the slide] @@ -223,19 +250,29 @@ </div> <div class="slide"> - <h1>Building a Large-Scale Ajax App (cont.)</h1> + <h1>Large-Scale Ajax Apps: For Example</h1> <ul> - <li>Examples</li> - <ul> <li>Code organization and packaging</li> <li>Speeding up app load time</li> <li>How much code stays on the server? Which code?</li> - <li>How to create maintainable code for - client-side-generated UI elements? DOM vs. strings of - markup.</li> + <li>Maintainable client-side UI code: + DOM vs. strings</li> + <li>Keeping business secrets out of the browser</li> <li>App security</li> - <li>Keeping proprietary business knowlege out of the browser</li> </ul> + + <div class="handout"> + [any material that should appear in print but not on the slide] + </div> +</div> + +<div class="slide"> + <h1>Further Questions: Supported User Agents</h1> + <ul> + <li>Backward compatibility / non-JS</li> + <li>Progressive enhancement (AKA 'unobtrusive Ajax') + vs. separate codebases</li> + <li>Mobile devices</li> </ul> <div class="handout"> @@ -244,27 +281,26 @@ </div> <div class="slide"> - <h1>Other issues, further questions</h1> + <h1>Further Questions: Accessibility</h1> <ul> - <li>Accessibility</li> - <ul> - <li>Accessible does not mean 'no _javascript_'</li> - <li>Accessibility is multifaceted</li> + <li>'Accessibility' can be nebulous</li> + <li>Does NOT mean 'no _javascript_'</li> + <li>Does include:</li> <ul> <li>Screen readers</li> <li>Text size</li> + <li>Text color</li> <li>Keyboard shortcuts</li> + <li>Other ???</li> </ul> </ul> - <li>Backward compatibility</li> - <ul><li>Progressive enhancement versus separate codebase</li></ul> - </ul> <div class="handout"> [any material that should appear in print but not on the slide] </div> </div> + </div> </body>
Modified: trunk/docs/oscon2006/cosmoScooby/ui/default/pretty.css (870 => 871)
--- trunk/docs/oscon2006/cosmoScooby/ui/default/pretty.css 2006-07-21 00:16:54 UTC (rev 870) +++ trunk/docs/oscon2006/cosmoScooby/ui/default/pretty.css 2006-07-21 20:48:08 UTC (rev 871) @@ -25,7 +25,7 @@ kbd {font-weight: bold; font-size: 1em;} sup {font-size: smaller; line-height: 1px;} -.slide code {padding: 2px 0.25em; font-weight: bold; color: #533;} +.slide code { font-family:Courier, "Courier New", monospace; font-weight:bold; } .slide code.bad, code del {color: red;} .slide code.old {color: silver;} .slide pre {padding: 0; margin: 0.25em 0 0.5em 0.5em; color: #533; font-size: 90%;} @@ -37,7 +37,7 @@ .slide img.leader {display: block; margin: 0 auto;} div#header { background-image:url(header_bg.gif); background-repeat:repeat-x; border-bottom:1px solid #48697f; - background-color:#4da1d0; line-height: 1px; } + background-color:#77badf; line-height: 1px; } div#footer { background-image:url(footer_bg.gif); background-repeat:repeat-x; background-color:#4da1d0; font-size: 0.5em; font-weight: bold; padding: 1em 0; border-top:1px solid #48697f; } #footer h1, #footer h2 { display: block; padding: 0 1em; color:#48697f; }
_______________________________________________ Commits mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/commits
