[ Summarizing Mitchell and Brendan and Mike's talks from memory -
probably missing big chunks. Sorry about the spelling, too. I'm
typing as fast as I can. ]
Mitchell Baker
At Mozilla developer day today. Listened to Mitchell talk about a
little of the organization history, and our current state. The
involvement and interest of companies in the org, since we're a
seperate legal entity (most of which we can't about, of course.)
We've come a long way. Talking about traffic numbers on the web
site as a level of interest. We've been working up the rankings
pretty quickly. Getting ready for 1.0 releases, since they will
be pretty large.
Mike and Brendan
Mike and brendan talked about our future technical direction.
libxul.so, extensions, platform compatibility. Their
demo was a little click and stars on the side of the browser that
ran through the entire talk. It uses something akin to apple's
<canvas> tag. I guess they didn't sleep last night
and hacked it up. Using cairo on all platforms. General roadmap
of the next two years to get to Mozilla 2.0. Developer
documentation. And it's mike and brendan, so it was funny.
Robert O'Callahan
Robert O'Callahan talking about future CSS-related items. Trying
to do neat stuff that we can do now. Transparent, non-rectangular
windows. Gave a cute little demo of a transparent octupus just
hanging out on the desktop, waving its tentacles. Talking about
SVG. The Gecko implementation is making good progress. It has
full integration with out DOM, CSS, scripting. They are shooting
to enable this in the 1.8 or 1.9 timeframe, based on the
yet-to-be-determined criteria. Nice demo. Using an SVG image as
the background in an HTML page that scales with the size of the
page. Adding column support. Really powerful layout primitive.
Allows for either specifying the number of columns, or fixed
height and will fill in as many columns as is required. Gave a
demo of Mozilla showing slashdot with columns in both modes. More
like how newspapers have been for a long time.
Talking about cairo. Want to use for all our graphics. Has
powerful vector graphics and high quality output. Has support for
arbitrary transformations. Put it on a Glitz backend and it has
hardware acceleration via opengl.
Screens historically have been about 100dpi. Starting to see
200dpi units now. Need to handle that. Plan is to make a CSS 1px
to be close to 1/96 of an inch, as fixed units. Rounded to whole
numbers of device pixels. Scale everything appropriately. This
requires a lot of infastructure changes. Can implement zoom at
the same time.
We're making a lot of progress. Great opportunity to make
Mozilla/FF the "must have" browser (on windows at least.) There's
little competition, hardware trends reward innovation, etc.
Aaron Leventhal
Aaron Leventhal talking about accessibility. Definitions: means
that software can be used by anybody. Generally talking about
people missing a sense, or an ability. Have to think about
problems in a different way. Free/open source software has a
special role to play. It empowers the community of engineers with
disabilities. They have access to daily builds, etc. Charitable
organizations and universities can participate and get involved.
Talking about the electronic curb cut effect. Originally for
disabled people, but everyone uses them (bikes, luggage, etc.)
Typewriter was designed for someone who can't see to write
letters, etc. Generally if you design for this, your software
will be better.
Don't assume that someone can see. People who can't see generally
use some kind of screen reader, screen magnification or other
items. One-handed typists will use a mouth stick, special
keyboard, etc. 8-10 percent of the male population is
color-blind. Need to consider that. Most people develop
disabilities later in life, most aren't born that way.
Government Procurement: Start with the list of Section 508
compliant software. Everyone is cautious of legal liabilities.
The goal is to create a critical mass of users with disabilities.
Microsoft has done a great job with accessibility. Apple is next,
Linux is last. 3 years behind.
Some technologies included: screen magnification. Linux has one,
kinda slow because no hardware accel. The windows one is nice
because it's a device driver and can take out colors if someone
can't see as well. Screen readers are hard. Sun has been trying
to get gnopernicus to work with Mozilla. You can't just navigate
plain text. Have to also have support for other controls.
Basically requires a "second" browser. Lost of assisitive
technologies go through the keyboard. Not many issues left here.
Voice input: dragon natural speaking is the leader on windows.
Not good on Mozilla. Works well in IE. Can do some near stuff.
Video access. Closed captioning.
[ Would you like to play a game of chess? ]
Talked about some various problems with parts of apps. Images in
dialogs. Calendar, as a sample. Can't navigate with keyboard,
etc. Can't use shift-F10 to get a context menu. Can't require
drag and drop.
What does a developer need to do? Don't break keyboard
accessibility. That's the best thing to do. Focus: make sure
that it's clearly visibile, and works sensibly. Don't ever hard
code color or sizes in your app. Breaks with high contrast
themes. Don't just set a foreground or background color.
All new technologies (web forms, etc) have to be known to screen
readers, require integration. Different APIs for all platforms.
MSAA on windows, ATK on linux.
Best way to figure out if there's a problem, get testing! Might
find things you will never find. Screen reader testers, in
particular.
Lots of work left to do. Some big problems. DHTML widgets are
basically not accessible. HTML does not provide enough widgets.
Even with web forms, authors will always need custom widgets. EU
might say that any pages that need to be accessible can not
have javascript in them at all. Important to fix this
problem. See the web site: http://www.accessmozilla.org.
Nice demo of a screen reader. Shows some of the problems. It
sure talks fast.
Nigel McFarlane
Nigel is talkin about application opportunities with XUL. This is
building software on top of the Mozilla platform. [ He covers a
lot of basics. ]
XUL isn't that useful by itself. You also need JavaScript, XPCOM,
network components and a lot of other elements. You also need
style. All of these things make up the platform. Mozilla is good
for younger folks and stundents, because you can start playing
with it at a pretty high level. Has a pretty easy place for
entry.
A good XUL application requires moving outside of the browser
space. You need to have a useful problem to solve. [ Lots of talk
about industrial design. ] Firefox has some industrial design.
Better than most free software, which has little or none.
Industrial design can be a good differentiator. You can build a
mouse trap for "fussy mice." Users are attracted to different
solution spaces.
Commercial spaces: XUL extends HTML in certain places. Better for
records management applications. i.e. menus and forms. Good for
the database world. Lots of other spaces as well.
Sounds hard? look at http://www.discoverdesk.com. One person.
Mostly done with self-study. Uses remote XUL. Clear direction
and no fear. Well done JavaScript code.
Deployment vs. design. Our platform provides numerous display and
deployment options. These are factors in service delivery, but
probably isn't as important as the application logic. Deploying
remote XUL is just a service hurdle.
Various web app idioms are common. Breadcrumbs, TOC, shopping
carts. There are similar idioms in RM apps. For example, screen
navigation vs. google search bar.
Bank example. Banks love to keep customers, and to charge you for
that service. Net banking is a service delivery and CRM is on the
minds of many banks. Banks are expanding net services to include
many functions - the beginning of a long trend. Include cashflow
analysis, payroll. XUL + chrome + web + local files could do this
easily. XUL apps could then aggregate of value-add on top of the
URL-based services that banks currently offer. Banks won't offer
you a scheduler for credit payments that minimizes the interest
you pay. But the 3rd party XUl application wrapped around their
web we might.
Mozilla Community applications - lots of examples. There are lots
of XUL-friendly apps. JS Console, JS Debugger, DOM inspector.
rginda's cview.
XUL developer app might be nice. Writing XUL documents. Running
XUl documents, Diagnosing problems. What paradigm? Web-style
coding ideas should be considered. By hand or generated? If
generated, then what? Reference material? Web pages, cview as
examples. In his opinion, generic builders aren't too useful.
Too general for a specific problem space. Insulates programmers
from useful XUL syntax. Fails to integrate more widely -
i.e. server-side Perl. But some XUL coding tasks are tedious.
Building trees, templates, box layout. Some solutions? Standard
solution (from graphics.) use a palette metaphor: additional
windows. It helps you build a dialog or window. The user stays
in control of the most of the canvas. In this case, the XUL
window.
What do you load into? What to report about loading? How do you
validate - this is missing in our product. The Moz runtime holds
all the app state. Use the standard runtime, if possible.
Minimize "special version" dependencies. What you run is what you
get. No special bugs due to using "the developer version." XUL
windows are owned by the app developer. Shouldn't be wrapped.
Don't distort made windows with extra UI.
Some thoughts on load time. Debug output isn't that useful, at
least for app developers. Needs to be seperated from other
output, ignored if possible. Need other kinds of debugging sinks
required. Need custom methods.
Apps for running XUL? What apps do we have? DOM inspector, JS
console, Java console. What can we add?
DOM inspector - Good tool, very popular. Packed with
functionality. Build well for web developers. Not quite right
for XUL workflows. Experimentation is needed (copy and hack.)
Other needed things: Chrome inspector - an explorer version that
probles for resources:// urls. RDF version that probes the chrome
registry. Same with an overlay inspector. Text version that
probes for <?xul-overlay?>. RDF version that probes the
overlayinfo db. Frameset inspector - simpler breakdown of a
single XUL window. i.e. <FRAMESET>, <FRAME>, etc.
Ad-hoc query tools. Data source query tools - i.e. MS access
style tool, prefers RDQL. Probles the state of a specified
datasource. Command query tool. Probes installed command
controllers. Same with template tools. Data injection tools.
DOM injector. Events, commands, etc. Into running instance.
Mozilla in the open source world? About 200 mozilla-based
applications. Most are secret due to commercial interests. We're
still waiting for a real proof of concept. A non-Mozilla open
source application that uses Mozilla to solve a different problem.
Linux UIs are inproving, but not yet ideal. See esr's rant on
CUPS. The GIMP is improving, but still clumsy.
Some obvious targets: Linux kernel config. Zope has wanted a
management UI for a long time. Libraries: PHP/PEAR and Perl/CPAN
both have server-side XUL libraries in need of work.
Finding a perfect application: project is already well maintained,
interesting strong on visual metaphors and fully open source.
Find something that has a horrible existing UI and has core
technolgists that need to be saved. Maybe - has a touch of 3D?
Show that longhorn-based "Virtual Observatories" aren't that
unique.
Good possibility: GRASS is a GIS application. Geographic,
resources, analysis, support and system. http://www.grass.itc.it. Big
job for several people.
XUL and Mozilla are reasonably bug-free. Pretty fast. Most of
the problems these days are technical. Get your skills in XUL,
CSS, JS and XPCOM. Get your skills in design and modelling.
Focus on one problem domain.
Bob Clary
Bob has worked for several years to try to bring various web sites
into the fold when their sites have used IE-specific or
non-standard HTML.
How do you measure compatibility? First, errors in the content.
Then by the layout. Most stuff is cause by real errors in css, or
javascript or in the content. Bob has done a lot of testing to
see how various errors in your html affect layout.
A testing strategy:
- Locate and fix all JS errors. Mozilla is really good at
this because of the JS console.
-
Location all pages which invoke standards mode layout. This can
cause a lot of problems if you're not aware of it. Just use
Quirks, if you don't want to bother.
- Locate and eliminate all CSS MIME errors. Lots of servers are
still serving up CSS files as plain text. In quirks mode, that's
ok, but not in standards mode.
- Locate and fix elimenate CSS errors. This is one of the
biggest problems today. Apparently no one knows how to do this.
- Check uses of ActiveX and Plugins. There are lots of times
when the W tag on the embed tag makes it possible to put stuff on
top of a flash plugin in IE. This affects us a lot.
- Investigate JS warnings for potential problems. This can be
really helpful! Don't just ignore them!
- Analyse errors and educate your developers. Use the above
methods to figure out how people are making mistakes, and then
educate them properly.
- Use Mozilla to develop and test new content. We have the best
standards, the best CSS, best JS support and really great tools
(DOM Inspector, JS debugger.) Odds are that if you get it working
in Mozilla, it will probably work in IE, too.
- Require new content to pass error checks. This seems silly,
but it's a great way to test. You can use mozilla to check your
content before deploying.
- Periodically recheck content and investigate changes.
What kinds of tools do we have now? The JavaScript console can
deliver both errors and warnings. It does report the CSS mime
error. It doesn't report CSS parsing errors, though. People do
have problems with the CSS validator that exists, though.
[ Goes through a web page that has errors in it. ]
Mozilla Spiders. The Spider is a Mozilla Web Application
implemented upon a web spider frameword first introduced on
DevEdge in June 2003 as CSpider. Spider can be run as an HTML web
application, as a remote XUL application or as a chrome
application in Mozilla. Can catch console and JS messages. Can
save logs and you can process them later. Can be extended to
analyse the contents to report on topics such as HTML validation,
page layout, plugins, simulate most mouse events and send results
to an external web application. Is very useful, even if it's
clumsy.
[ Demo of the spider program and going through a log. ]
Robert O'Callahan
[ Jumped in in the middle here. He's talking about backwards
compatibility. ]
Talking about the IE approach to backwards compatibility. MS is
completely unwilling to break any pages, ever. This is why they
aren't willing to implement new standards.
Policy #1: You can use quirks to control how the engine will
render. DOCTYPE is the way to do this. Pro: compatibility is
preserved. Con: too many revision levels (especially in browser
multiculture.) Con: engine size keeps getting bigger. Pro/Con:
Developer is seduced by the default mode.
Policy #2: Pages assume standards-correct rendering. Browser bug
workarounds must be standards-OK. We break underspecified pages
in arbitrary ways. Pro: build a smaller and simpler engine.
Pro/Con: resists browser monoculture. Con: can web developers
deal with this? What about non-standard extensions? Mozilla has
a number of these.
Policy #2b: Pragmatic standards. Pages assume standards-correct
rendering. Where current behaviour is incorrect or
underspecified, sucessive releases will either make it more
correct, or preserve it. Non-standard extnesions: depends on the
extension. Check before you do it. This is rougly our current
policy. Caveat: it's all best effort. Try to avoid breaking
pages, but it does happen from time to time. This is his
suggestion for what we do in the future.
How can a web developer know if they are depending on a Gecko bug?
Test in other browsers: Opera, KHTML/Safari. It's easy to tell if
you're using a Gecko extension: the Mozilla namespace -moz-prefix.
Are there any icebergs looming? Kind of hard to tell. But we
will know as we gain market share. Anything else to do in the
future with developers? Features, etc? Hard to tell.
How can you help? Test your favorite web apps! You never need be
surprised that Moz 1.x breaks your app. If we know early enough,
we can usually fix it. Supply a good patch, and we'll definitely
fix it. At least test "version X beta" and "version X RC."
Managing Platform Evolution. How is this different from evoloving
Flash, Win32, Java Class Library, MSWord, etc? It isn't, but the
web has a bigger install base. Web has fiat-standards. Web is
both more and less complex. Web permits somewhat looser
interpretations.
Myk Melez
Myk is going to talk about hacking rss feeds into Thunderbird.
What is it? A thunderbird extension for reading syndicated
content in your favorite email client. Supports RSS 0.9x 1.0, 2.0
and Atom. Maps RSS "items", Atom "entries", blog "posts", allows
news "stories" to email "messages", which works pretty well.
- post|story author -> message sender
- post|story title -> message subject
- post|story date -> message date
- post|story URL/content -> message
Stores messages in your regular mail mail folders and treats them
like email. You can use use filters. Labels, mark read and
unread.
All you have to do is subscribe to the feed via the feeds manager.
Forumzilla periodically checks for new stories and downloads them
to folders of your choice. You can put stories into one folder,
or in seperate folders. You can set per-site time to check when
things are updated. It should be included in thunderbird as a
native feature soon.
Some extra notes about online discussions. Web discussion forums
have taken over from email: worse is better. Email clients are
specialized for discussion and have a mature feature set for
dealing with it, while web browsers are generic application hosts
with no specific support for discussion. The interfaces might be
different (for now) but the goal and content are similar. Users
don't care what format is used, just that they can access
information.
[ Demo of forumzilla. Neat stuff. Pretty flexible in terms of
how you can organize feeds into folders. Can download and store
feeds in remote IMAP folders. Lots of other niceties. ]
[ Demos and talks about a couple of apps, including LiveBookmarks,
HelixPlayer and some other stuff. ]