Data Gathering for FF 3

[Sherman Dickman]

All,

We're rapidly ramping up research and data gathering activities for
Firefox 3.0 and beyond. The initial focus will be on market
research, technology trends, competitive analysis, and user feedback.

I would like to get everyone's thoughts on potential long-term
themes, goals, questions that would be interesting to answer, and
areas where it would be useful to have better data. Rather than
focusing on individual features, I think it would be helpful to keep
the discussion at a high-level, and to identify how groups of
features can support one another in theme, goal, use-case, etc.

Here's a starter theme (filled with personal biases!) to get the
discussion rolling. Please feel free to comment or to suggest other
areas of opportunity in whatever format works best for you.

Theme: Innovation on the data a user discovers online

Goal: Enable end-users to build a valued asset base
------------------------------------------------------------
* If mail serves as the de facto database for interpersonal
communications, can Firefox fulfill a similar role for information
found on the Web?
* In addition to Web history and bookmarks (Places revisited?), what
other forms of information would be of value to end-users? Full
text? Micro-formatted content such as addresses or events?
* How could information assets be used in ways that provide the user
with more leverage, value, or control over their online experience?
* What parallels can be drawn to other desktop applications that
manage information (i.e. Mail, RSS readers, media applications,
desktop search, etc.)?
* Areas for data collection:
* Personal information management or personal content management
* Personal information networks
* Desktop search

Goal: Extend scale and reach through data sharing
------------------------------------------------------------
* Can we make it easy for people to share the data they've discovered
online in a massively scalable way (i.e. mail, IM)?
* Can this be done in a way that provides unique benefits to the
recipient, and thus, better demonstrates the value of Firefox to non-
users?
* How do the benefits of Firefox begin to amplify when participants
are using the same platform?
* Areas for data collection:
* Communication applications and adoption (mail, IM, VoIP, P2P)
* Collaboration (online services, calendaring, social networks)

Goal: Attract new types of developers to our ecosystem
------------------------------------------------------------
* Can the information that a user discovers online be thought of as a
platform for innovation? In what areas? Parsing, data-mining,
visualization, local-data mash-ups, integration with online
services? How can research, innovation, and communities form around
these areas?
* How could this data interface with online services, and can we make
it easier for developers to build on top of that?
* Areas for data collection:
* Developer and technology trends and adoption
* Microformat and semantic data trends and adoption
* Local storage and local application hosting (are there
existing parallels in the market?)
* Backup and sync services (from OS vendors and 3rd party
services)

- Sherman

[Jon Smirl]

On 7/28/06, Sherman Dickman <she...@mozilla.com> wrote:
> We're rapidly ramping up research and data gathering activities for
> Firefox 3.0 and beyond. The initial focus will be on market
> research, technology trends, competitive analysis, and user feedback.

What are the plans for XULrunner as a platform? The code looks to be
in good shape, what about product management?

Branding, logos, umbrella advertising, etc
A good book with real content, not a reprint of XULplanet
Tutorials and sample code, opengl is an excellent example,
http://www.opengl.org/code/
Instructions for packaging and distributing a XULrunner app
A final name for XULrunner
Joint tradeshow events with Mozilla and XULrunner apps developers
Tradeshow presentations on building XULrunner apps
An analysis of why XULrunner will succeed and where Java failed.
FAQ on the why and what of XULrunner

These are a few of the product marketing activities associated with a
platform launch.

--
Jon Smirl
jons...@gmail.com

[Benjamin Smedberg]

Sherman Dickman wrote:
> All,
>
> We're rapidly ramping up research and data gathering activities for
> Firefox 3.0 and beyond. The initial focus will be on market research,
> technology trends, competitive analysis, and user feedback.
>
> I would like to get everyone's thoughts on potential long-term themes,
> goals, questions that would be interesting to answer, and areas where it
> would be useful to have better data. Rather than focusing on individual
> features, I think it would be helpful to keep the discussion at a
> high-level, and to identify how groups of features can support one
> another in theme, goal, use-case, etc.
>
> Here's a starter theme (filled with personal biases!) to get the
> discussion rolling. Please feel free to comment or to suggest other
> areas of opportunity in whatever format works best for you.
>
>
> Theme: Innovation on the data a user discovers online
>
> Goal: Enable end-users to build a valued asset base
> ------------------------------------------------------------
> * If mail serves as the de facto database for interpersonal
> communications, can Firefox fulfill a similar role for information found
> on the Web?

This sounds like a too-broad question to answer properly. You can
communicate pretty much anything over the web, including mail and
calendaring and all sorts of domain-specific information. We can possibly
categorize the "grand everything" in generic ways (through
history/bookmarks/fulltext search), but increasingly we should allow users
to "install" domain-specific views/visualizations/handling of information.

Domain-specific apps have the opporunity to categorize and present specific
kinds of web data to the user in much more usable ways. Songbird and
Democracy player are two new applications that will be release about the
time of FF3 that are optimized for downloading and categorizing audio/video
from the web, and working with web services in the process.

There is increasingly a "web outside of the browser", and I think Firefox
should embrace this phenomenon and provide integration points so that users
have a way to explore and use this new web.

> * Areas for data collection:
> * Communication applications and adoption (mail, IM, VoIP, P2P)
> * Collaboration (online services, calendaring, social networks)

One common thread between all the "web 2.0" sites is that they allow sharing
and discussion by the people they serve. It would be interesting to examine
how enhancements to the browser could enhance this sharing system (perhaps
browser support for open authentication mechanisms like OpenID would prove
helpful, for example).

> Goal: Attract new types of developers to our ecosystem

I would add: to what extent can enhancements or changes in the browser
encourage users to become authors on the web? What are the barriers to entry
to becoming a web participant, and not just a web consumer?

--BDS

[Deb Richardson]

I think the implicit (and perhaps obvious) overarching question here is,
"How can we improve Firefox to make the Web better for users?"

With this in mind, I've messed around a bit with the wording and formatting
of the core themes and goals I've distilled from Sherman's post (probably
missing stuff in the process), then added a few other possible goals and
themes.

Hopefully this is along the lines of the sort of discussion you were looking
for...

-----

Theme: Increase the value and utility of the information individuals
encounter and gather while using the Web.

* Goal: Improve the quality and quantity of the information that is
automatically accumulated while a user is on the Web.

* Goal: Increase the value of this information by improving the tools for
viewing, searching, manipulating, analyzing, and combining the information a
user gathers.

* Goal: Further increase the value of this information improving the tools
for sharing the information a user gathers, and for combining this
information with other users' information.

* Goal: Give developers new tools to extend the value, functionality, and
utility of the user's information.

* Goal: Improve the user's ability to expand or restrict what information is
automatically accumulated by the browser.

* Goal: Allow users to easily sync their information between computers or
devices.

----
Other possible themes?

Theme: Make it easier for users to produce Web content.

Theme: Make it easier for users to interact and collaborate on the Web.

Theme: Make it easier for users to customize and control their experiences
on the Web.

Theme: Make a user's Web experiences safer and more secure.

Theme: Make browser technology more transparent so users spend less time
thinking about the tool and more time just using the Web.

~ deb

[natmaster]

I see extending Firefox as a platform as an important goal. Let me
explain:

Firefox has thousands of extensions, and really a lot of power to be
customized for each user. However, I haven't seen many (if any)
pre-built customizations. Flock doesn't really count b/c it's simply
the affect of the OSS model - they're expanding on the code. What I
really think should be done is easier creation of more deeply
customized Firefox PACKAGES. Almost every technology enthusiast has
already adopted Firefox, but the market is still lacking in OEM bundles
and businesses (network deployment). If tools could be forged, and
further enhancements to Firefox's ability to customize made, I think
there would be a lot more adopting, and possibly some more interesting
things showing up.
Firefox's defaults and feature set are made for the average user - but
no one is really average. How many people actually show up in the
'average usage' range? Firefox is already starting to attack niche
markets, and I think there can be much more done with this. I think
this is the one defining factor that makes Firefox great (and separates
it from the other browsers - no matter how similar their basic features
may be).
I would love to see the day when customized packages of Firefox show up
on people's personal websites targeting their viewers usage models. PC
builders make PCs for gamers, businesses, home users, entertainment,
students. They could further differentiate their PCs by providing
customized Firefox packages optimized for those users they are
targeting. I think this would trigger a huge demand for Firefox
pre-bundled with PCs - which also implies destruction of IE's dominant
market share, since few really CHOOSE IE. And finally 'Firefox
packages' would allow network admins at businesses to easily provide
the browser installation and settings they need. Simple, easy to use
tools would allow them to waste little time on this, and thus encourage
adoption (since time is money in their world). Businesses could also
make different packages for presentational environments, or even public
(internet cafes?) environments. The needs for each user and group is
not only unique to them, but to their situation. Often groups of people
have the same needs, and providing one package would allow them to
lessen the need for 'customization time' - something that often pushes
users away from linux.

Yes, Firefox has great extensible capabilities - especially with it's
open model. It certainly outperforms any other browser in this respect.
This is why it should be a primary focus. It is the defining factor.
The reason for greatness, the vessel for innovation. Because of the
demand for diversity and niche abilities, these functions should be
enhanced and made EVEN EASIER. I'm not saying they aren't great today;
I'm saying I expect a better tomorrow. Let there be no question of the
capabilities of Firefox.

Sherman Dickman wrote:
> All,
>
> We're rapidly ramping up research and data gathering activities for
> Firefox 3.0 and beyond. The initial focus will be on market
> research, technology trends, competitive analysis, and user feedback.
>
> I would like to get everyone's thoughts on potential long-term
> themes, goals, questions that would be interesting to answer, and
> areas where it would be useful to have better data. Rather than
> focusing on individual features, I think it would be helpful to keep
> the discussion at a high-level, and to identify how groups of
> features can support one another in theme, goal, use-case, etc.
>

> - Sherman

[Alex Faaborg]

Since this is my first post, I'll introduce myself: I'm Alex and I've
spent the last couple of years researching ways to leverage large-scale
semantic networks to improve the user experience of Web browsing and
search. I've also been involved with the semantic web research
community.

I agree with all of the goals Sherman stated. Here are a few comments:

> In addition to Web history and bookmarks (Places revisited?), what
> other forms of information would be of value to end-users? Full
> text? Micro-formatted content such as addresses or events?

I believe detecting information expressed in a microformat and linking
this information to particular actions and applications (like
associating calendar events with the action of adding the event to your
calendar), is definitely one of the ways Firefox could differentiate
itself from other browsers. But more importantly, it is a feature that
(1) will be meaningful to end users, and (2) will further innovation on
the Web.

(1) Meaningful to End Users:
Right now a user spends a lot of time copying and pasting structured
information from the Web into various applications. For instance, a
user might copy the times and locations of sessions at a conference
into a calendar application. Or, the user might copy and paste the
various attributes of a journal publication into an application that
keeps track of academic citations. Streamlining these types of actions
into a single click will make the user's life easier.

(2) Further Innovation on the Web:
Right now the semantic web is facing a chicken and egg problem. Web
developers are not encoding information in any kind of semantic markup
because there is no compelling reason to do so, and Web browsers are
not detecting semantic markup because no one is creating it.

Mozilla is in a unique position to influence the emergence of semantic
content on the Web. Giving Firefox the ability to detect semantic
content will encourage Web developers to add semantics to structured
data (like calendar events) on pages they make.

Since you asked that we not focus on individual features and instead
keep the discussion on a high level, I'll create a new thread to
discuss the user interface of microformat detection, and a strategy for
creating a micro format developer ecosystem.

-Alex

[Alex Faaborg]

> Please feel free to comment or to suggest other
> areas of opportunity in whatever format works best for you.

Here is another idea for a theme (goals are not quite as high level)

Theme: Put users in control of their personal information

Goal: Enable users to track the distribution of their personal
information
------------------------------------------------------------
* Store the information that users submit to web sites in their history
* Enable users to easily search their history to answer questions like:
-"Who should I notify about my new cell phone number?"
-"Did I really mistype my address when I placed that order?"
* How would users benefit from this type of data collection?
* This is essentially spyware that is designed to help the user:
-How will users react?
-How will the press react?
-How do we secure the data so malicious programs can't get to it
-Turned off by default?

Goal: Enable users to browse the Web "off the record"
------------------------------------------------------------
* Enable users to put Firefox into a state in which no information is
recorded locally about their actions on the Web. Ambiently display in
the user interface that Firefox is in this mode.
-Feature of Safari in OS 10.4, 4/29/2005
-Firefox extension named Stealther, 3/15/2006
* Possible talking point: "Firefox takes your privacy seriously"
* Useful for public machines in computer labs, Internet cafes, etc.
* Is this a reason for people to switch to Firefox that no one will
admit to?
* Firefox currently has the wrong model for dealing with personal
information (control-shift-delete):
-Users should be able to take advantage of saved passwords and
history,
and still be able to do things on the web (like buying a present for
their
girlfriend) that do not get recorded. They shouldn't have to clear
all of
their personal information every time they want to go off the record.
-This would also fix a usability problem with the password manager
dialog box. Firefox currently asks the user: "Do you want password
manager to remember this login?"
Yes: Firefox remembers that you went to the site
No: Firefox does not remember that you went to the site
Never: Firefox remembers that you went to the site
https://bugzilla.mozilla.org/show_bug.cgi?id=330884

[pcab...@yahoo.com]

One thing that makes Firefox 2 different is support for third party
providers: web feed readers and phishing black lists. I believe, users
need this support a step further specifically for web mail. Firefox 2
also partially removes the support for desktop email apps, but it does
make sense to provide the necessary hooks to support "web mail plugins"
provided either by the community of by the web mail providers
themselves. In fact it makes even more sense than web feeds comparing
the user base of both technologies.

Another one is on line bookmarks. Mozilla could develop a protocol for
bookmarks/everything server synchronizing and sharing while at the same
extending the bookmarks capabilities as it has been mentioned before,
to add notes, customizable flags, multiple web pages version storage,
scheduled refresh/storage.

I also believe that a release (2.1?) solely focused on performance
should be added. No features, not a single string changed but just
memory leaks, code cleanup and performance improvement overall. Then, a
release solely focused on printing enhancement (2.2?), including save
as PDF capabilities. IE7 is almost ready to ship and then suddenly 70%
of Firefox's "perceived" competitive advantage (tab browsing, popups,
web feeds, anti-phishing, integrated search) will disappear. Certainly
Firefox still will be better: SVG, Xforms, web standards, security,
extensibility, but those are much more difficult to sell, so Firefox
needs a killer feature that MS can't match (as it has proved recalling
PDF export from Office 2007). It has been said Firefox is not about
market share but choice, but unfortunately both don't travel alone: I
can't choose if I don't know about the options, and I can't know if
there's no market share.

To summarize, I would add these goals:

- Make Mozilla products an easy decision for IT managers:
- delivering best performance/security/manageability
(.msi)/customization (CCK + themes + extensions)
- delivering killer features: PDF, perfect printing, web page (think
web reports) archiving, spell checking, session management

- Make Firefox features more discoverable:
- deliver a tutorial for key Firefox features
- deliver an "assistant" (don't think clippy, think simple dialogs
and overlays) that introduces to UI elements like the anti-phishing
ballon, for other features like microsummaries, search plugins, web
feeds, places, themes, extensions, etc.

Percy

[rudi...@gmail.com]

Greetings,

Coming from a university teaching and research background, I am trying
to use the web as a teaching medium. These days there is a ton of
information available to people. Your favorite search engine can dig up
things about pretty much any topic you can imagine. Feeds and bookmarks
help you to gather and distribute information very effectively. Firefox
did a great job introducing the live bookmarks. There are plenty of
extensions out there that serve the different interests of the user
community. They help to make the user experience more interactive.

We are working with a lot of imagery that our students use for visual
analysis. This is certainly one area of interactivity that browsers to
my knowledge have not entered at all. The functionality that I would be
looking for is simple. So far browser just display images. Period. A
little zooming functionality here and the capability to roam around in
a image there. Combine it with some information box that tells you
something about cursor position and current color value. And you got
yourself image analysis functionality. Very basic but quite sufficient
for a lot of purposes.

With this kind of simple means you reach an entirely different level of
interaction. You can extend this sort of theme to any level you like.
Combine the raster information with vectors (SVG etc.). Throw in some
simple statistics.

Hope this point of view makes somewhat sense.

Cheers,
Rudi

[Alex Graveley]

What I would love to see is further blurring of the lines between what
is the web and what is a native application. I suspect confusion
already exists for a lot of users today, with some applications
accessed through the browser, some through the mechanism provided by
the OS, some requiring a network connection and some not.

Instead of these unnecessary distinctions, I should be able to browse
to a new "Firefox Native" enabled site, decide that it is valuable, and
click an "Install" button to have it appear in the Start menu or on the
Dock just like any other application. The site could even tailor
itself to this mode and enhance it's look to that of a native
standalone interface over a document interface.

To facilitate this, Mozilla can work to educate developers on how to
write better application code that can work without network access, or
that can behave more like a native application. By adding application
interchange interfaces for accomplishing things like DnD and copy/paste
(either from the OS or another web site) the lines signifying where the
web starts and ends further evaporates.

I think this is where Firefox can go that no existing platform vendor
can, all of whom are competing for application & developer lockin.

-Alex

[Chris Hubick]

On Fri, 28 Jul 2006 12:41:02 -0700, Sherman Dickman wrote:
> I would like to get everyone's thoughts on potential long-term
> themes, goals, questions that would be interesting to answer, and
> areas where it would be useful to have better data. Rather than
> focusing on individual features, I think it would be helpful to keep
> the discussion at a high-level

Is there an appropriate time/place for a web developer such as myself to
offer up some mid to lower-level 'pet bugs' in Bugzilla for potential
prioritization?

--
Chris Hubick
mailto:ch...@hubick.com
http://www.hubick.com/

[Axel Hecht]

Sherman Dickman wrote:
> All,
>
> We're rapidly ramping up research and data gathering activities for
> Firefox 3.0 and beyond. The initial focus will be on market research,
> technology trends, competitive analysis, and user feedback.
>
> I would like to get everyone's thoughts on potential long-term themes,
> goals, questions that would be interesting to answer, and areas where it
> would be useful to have better data. Rather than focusing on individual
> features, I think it would be helpful to keep the discussion at a
> high-level, and to identify how groups of features can support one
> another in theme, goal, use-case, etc.
>
> Here's a starter theme (filled with personal biases!) to get the
> discussion rolling. Please feel free to comment or to suggest other
> areas of opportunity in whatever format works best for you.
>
>
> Theme: Innovation on the data a user discovers online

One thing that I consider important in this theme is that we shouldn't
try to do more data collection and processing than the user understands.
As an example, local full text indexing and search may be of great value
to users, but only to those that understand the difference between that
search and a regular websearch. I can easily imagine that a good portion
of our users may not fully understand the limitation of a local search,
and understands when to use which. That of course depends on the UI to
some extent.

That poses an interesting question itself, should we limit ourselves to
developing only features that we want to be on by default, or even
shipped by default? Hint, I don't think so.

> Goal: Enable end-users to build a valued asset base
> ------------------------------------------------------------
> * If mail serves as the de facto database for interpersonal
> communications, can Firefox fulfill a similar role for information found
> on the Web?

Could you elaborate on this one?

> * In addition to Web history and bookmarks (Places revisited?), what
> other forms of information would be of value to end-users? Full text?
> Micro-formatted content such as addresses or events?
> * How could information assets be used in ways that provide the user
> with more leverage, value, or control over their online experience?
> * What parallels can be drawn to other desktop applications that manage
> information (i.e. Mail, RSS readers, media applications, desktop search,
> etc.)?
> * Areas for data collection:
> * Personal information management or personal content management
> * Personal information networks
> * Desktop search

One interesting talk at this years XTech was how to map microformats to
RDF, making the case for the semweb once again. The case as well as the
problems it faced are to some extent real.

This would raise the question, did the semantic web die? If so, or not,
do we know why?
That should help us in understanding how much *information* we can
actually expect to be encoded in a machine-readable way.

> Goal: Extend scale and reach through data sharing
> ------------------------------------------------------------
> * Can we make it easy for people to share the data they've discovered
> online in a massively scalable way (i.e. mail, IM)?
> * Can this be done in a way that provides unique benefits to the
> recipient, and thus, better demonstrates the value of Firefox to non-users?
> * How do the benefits of Firefox begin to amplify when participants are
> using the same platform?
> * Areas for data collection:
> * Communication applications and adoption (mail, IM, VoIP, P2P)
> * Collaboration (online services, calendaring, social networks)

I'd second bsmedberg's comment here. I think that one of the initial
design guidelines and reasons for success of Firefox was to get the
application out of the way.
I would think that a valuable alternative of getting more communication
threads inside firefox would be to make it easy to get a communication
thread out of firefox. Maybe the content handlers we're using for feeds
now is already heading in that direction, I haven't grasped where Ben is
heading with that.

> Goal: Attract new types of developers to our ecosystem
> ------------------------------------------------------------
> * Can the information that a user discovers online be thought of as a
> platform for innovation? In what areas? Parsing, data-mining,
> visualization, local-data mash-ups, integration with online services?
> How can research, innovation, and communities form around these areas?
> * How could this data interface with online services, and can we make it
> easier for developers to build on top of that?
> * Areas for data collection:
> * Developer and technology trends and adoption
> * Microformat and semantic data trends and adoption
> * Local storage and local application hosting (are there existing
> parallels in the market?)
> * Backup and sync services (from OS vendors and 3rd party services)

Axel

[Aaron Leventhal]

Applications:
- Bring the simplicity of authoring early HTML back to the web, but with
much added power to create rich internet apps (or whatever people want
to call them)

Documents:
- Make the web an open platform for document sharing and collaboration,
by directly supporting important standards such as ODF

Health of the platform:
- Get new owners for important orphaned areas of the code, such as the
editor core. All the coders for that have disappeared and no one seems
to be comfortable maintaining it.

- Aaron

[Benjamin Smedberg]

Aaron Leventhal wrote:

> Documents:
> - Make the web an open platform for document sharing and collaboration,
> by directly supporting important standards such as ODF

I think it would be fruitful to think about supporting PDF natively as well.
We now have in cairo the graphics backend to do it.

--BDS

[Jon Smirl]

Are things set up now so that PDF or ODF could be a full-featured
dynamically installable module (not a plugin)? We have to careful not
to increase the memory footprint on limited machines. I'd like to see
SVG become a module too now that the hooks that it needs are known.

--
Jon Smirl
jons...@gmail.com

[Matthew Gertner]

We've been working for over a year on a next-generation web browser,
packaged as a Firefox extension, so perhaps some of our experiences
could be of value to this discussion. The key functionality that we have
added to Firefox includes:

- Authenticated identity (via PKI and digital certificates) inside the
web browser.
- Real-time presence for contacts (including a sidebar-hosted buddy list)
- Resource-based (i.e. RDF) framework for management of domain-specific data
- Local storage of resources (using SQLite and mozStorage)
- Template-based display of resources (as HTML, XUL, etc.)
- Peer-to-peer resource distribution (via TCP or UDP, automatic
NAT/firewall traversal)
- BitTorrent support

Based on your description, I think we are addressing a lot of the very
same issues that you mention. Our framework makes is straightforward to
manage domain-specific data of various types (bookmarks, media file
metadata, calendar events, restaurant reviews, etc.). This data can come
from the user's machine or from the web. It can be searched efficiently
in the local database and manipulated programmatically using the RDF
APIs already included in Mozilla. Data can also be distributed (share,
synchronized, replicated) using P2P networking so a lot of apps that
would currently require a centralized server can do without; you can
deploy things like serverless shared calendaring, bookmark sharing, etc.
I should mention that we are planning to open source our code later this
year.

This raises the question of whether Mozilla should focus on adding
features of this type to FF 3.0 or rather on making it the best platform
possible for extension developers to build upon. My view on this is
obviously highly self-serving since I'm not particularly keen to compete
with Mozilla on features, but I do think that the key differentiators
for Firefox is the awesome Mozilla platform that enables third parties
to extend the browser. I believe there is a strong case to be made for
"letting a thousand flowers bloom" rather than trying to add these
features directly to Firefox.

Seen in this light, some examples of what I would personally like to see
in FF 3.0:

- Improved RDF support. I know that RDF has a bad rep in the Mozilla
community, but I think this is because it has been used in many areas
where it wasn't the right tool. The kind of features that we're talking
about benefit greatly from some sort of general-purpose data model and
RDF is very good at this (Axel, you hit the nail on the head in this
respect). What could be improved is: a) a less verbose API (I have
specific ideas about this) and b) proper support for multithreading.
- In general, better support for multithreading. There doesn't seem to
be any reason for things like the MIME service not to be threadsafe, and
it's hard to create a responsive user interface if you have to run
everything in the UI thread. Same goes for XPConnect and a bunch of
other stuff.
- Extension dependencies. People like us can deploy frameworks on top of
Firefox that others can build upon, but this falls down if hierarchical
dependencies can't be handled properly.
- More consistent data types. There are a whole bunch of data models in
Mozilla (JavaScript, variants, mozStorage, RDF, etc.) and they aren't
particularly compatible. Personally I'd love to see a small set of
universal data types (basically string, integer, decimal, date and blob)
that are used everywhere and convert automatically (so I can grab a date
from an RDF data source, use it in JavaScript and then write it to a
database, for example).
- Better support for advanced UI features like notification icons (the
famous system tray), alert bubbles, shell integration and the like.
- Reduced memory consumption. Firefox isn't as bad as people make it out
to be, but when you're building on a platform it can never be lean and
mean enough.
- ...

I'm sure I can come up with a lot more but this mail is already getting
long. I probably sound like a kook who is plugging his own agenda but I
really believe there should be some serious soul-searching about how
many sexy modern Web 2.0 features should be added to Firefox, as opposed
to continuing to improve the platform and letting extension developers
duke it out in the marketplace.

[Benjamin Smedberg]

Matthew Gertner wrote:
> We've been working for over a year on a next-generation web browser,
> packaged as a Firefox extension, so perhaps some of our experiences
> could be of value to this discussion. The key functionality that we have
> added to Firefox includes:
>
> - Authenticated identity (via PKI and digital certificates) inside the
> web browser.
> - Real-time presence for contacts (including a sidebar-hosted buddy list)
> - Resource-based (i.e. RDF) framework for management of domain-specific
> data
> - Local storage of resources (using SQLite and mozStorage)
> - Template-based display of resources (as HTML, XUL, etc.)
> - Peer-to-peer resource distribution (via TCP or UDP, automatic
> NAT/firewall traversal)
> - BitTorrent support

Given an ideal technical situation, how many of these features do you think

1) will be used by a large majority of users?
2) should be part of the browser itself?

It seems to me that many of these features are either niche (bittorrent) or
are better handled by separate applications (buddy list), but that the
browser should provide integration hooks so that extensions can provide
these services.

> - Improved RDF support. I know that RDF has a bad rep in the Mozilla
> community, but I think this is because it has been used in many areas
> where it wasn't the right tool. The kind of features that we're talking
> about benefit greatly from some sort of general-purpose data model and
> RDF is very good at this (Axel, you hit the nail on the head in this
> respect). What could be improved is: a) a less verbose API (I have
> specific ideas about this) and b) proper support for multithreading.

I could not disagree more. RDF is a disaster as a data model because of its
simplistic triple notions. We should rip RDF out of our platform entirely,
and if extensions (like allpeers) want to do RDF manipulation, they should
write their own APIs (which makes requirements like multithreading easy).
The cost of trying to really support RDF properly doesn't match up with its
actual use on the web or a user-driven web model (as opposed to a
data-driven web model).

--BDS

[Matthew Gertner]

Benjamin Smedberg wrote:
> Given an ideal technical situation, how many of these features do you think
>
> 1) will be used by a large majority of users?
> 2) should be part of the browser itself?
>
> It seems to me that many of these features are either niche (bittorrent)
> or are better handled by separate applications (buddy list), but that
> the browser should provide integration hooks so that extensions can
> provide these services.

Total agreement. I'm not sure if I made my point clearly but that's
exactly what I was trying to say in my original post.

> I could not disagree more. RDF is a disaster as a data model because of
> its simplistic triple notions. We should rip RDF out of our platform
> entirely, and if extensions (like allpeers) want to do RDF manipulation,
> they should write their own APIs (which makes requirements like
> multithreading easy). The cost of trying to really support RDF properly
> doesn't match up with its actual use on the web or a user-driven web
> model (as opposed to a data-driven web model).

I'm not married to RDF per se but I do think that a general-purpose data
model of some sort has a lot of value. I should mention that we use
schemas in conjunction with RDF so that we can support things like
subtyping and polymorphism. I'm very interested to learn more about why
you object to its "simplistic triple notions" since it seems to me that
any general-purpose model is going to be similar. But this probably
isn't the right forum for that.

Matt

[Robert Sayre]

Matthew Gertner wrote:
>
> - Resource-based (i.e. RDF) framework for management of domain-specific
> data

The problem with the RDF data model is that it is always possible to
make a case for it. I think this discussion would be more productive if
you focused on a concrete example. I can tell you that my first question
will be whether it is necessary to identify every node with a URI.
Nearly everything in Mozilla comes with a base URI, so I'm not sure it's
necessary past that. Something like Google's BigTable might be good...
we wouldn't need the large scale distributed aspects of it, of course. I
don't think we want to build anything ourselves.

> - Peer-to-peer resource distribution (via TCP or UDP, automatic
> NAT/firewall traversal)
>

Some of the networking code might be useful, given the WHAT-WG APIs,
session restore, and prefs stored on the network. For example, how do
you detect those wifi firewalls that block all traffic until the user
signs into a web page?

-Rob

[Sherman Dickman]

On Jul 29, 2006, at 7:36 PM, Deb Richardson wrote:
>
> ----
> Other possible themes?
>
> Theme: Make it easier for users to produce Web content.
>
> Theme: Make it easier for users to interact and collaborate on the
> Web.
>
> Theme: Make it easier for users to customize and control their
> experiences on the Web.
>
> Theme: Make a user's Web experiences safer and more secure.
>
> Theme: Make browser technology more transparent so users spend less
> time thinking about the tool and more time just using the Web.
>
> ~ deb
>

Hi Deb,

Lots of great thinking here, and it would be great to explore some of
these in more detail. Would you care to go a bit deeper on each of
these, perhaps three to five bullets each to highlight some of the
possibilities?

Sherman

[Axel Hecht]

Benjamin Smedberg wrote:
> Matthew Gertner wrote:

<...>

>> - Improved RDF support. I know that RDF has a bad rep in the Mozilla
>> community, but I think this is because it has been used in many areas
>> where it wasn't the right tool. The kind of features that we're
>> talking about benefit greatly from some sort of general-purpose data
>> model and RDF is very good at this (Axel, you hit the nail on the head
>> in this respect). What could be improved is: a) a less verbose API (I
>> have specific ideas about this) and b) proper support for multithreading.
>
> I could not disagree more. RDF is a disaster as a data model because of
> its simplistic triple notions. We should rip RDF out of our platform
> entirely, and if extensions (like allpeers) want to do RDF manipulation,
> they should write their own APIs (which makes requirements like
> multithreading easy). The cost of trying to really support RDF properly
> doesn't match up with its actual use on the web or a user-driven web
> model (as opposed to a data-driven web model).
>

Mind letting us know what you're comparing it to explicitly? I wonder if
we're supposed to compare labeled directed graphs with ... tables?

Axel

[Sherman Dickman]

On Aug 1, 2006, at 4:47 AM, Axel Hecht wrote:

>
>> Goal: Enable end-users to build a valued asset base
>> ------------------------------------------------------------
>> * If mail serves as the de facto database for interpersonal
>> communications, can Firefox fulfill a similar role for information
>> found on the Web?
>
> Could you elaborate on this one?

Sure, here are a couple of thoughts, and I'll focus on user value as
opposed to a technical discussion... Think about the information
that gets exchanged via email: discussions, contacts, documents,
photos, links, addresses, to do items, dates, meeting info... We
keep and organize messages because there's an an incredible amount of
value and utility attached to having this information accessible.
Not only is the content within messages valuable, but the mail header
provides additional metadata for message search, mail rules, column
sorting, etc. Finally, sharing this data is easy since mail
applications have built-in support for addressing and communication.

Through browsing the Web, Firefox users also build up an asset base
that includes cached content (Web history and download history) and
saved content (bookmarks). But the wealth of information that can be
found online is essentially lost or stuck within individual service
silos. The idea behind this particular theme is to enable users to
build up a valued Web asset base that can be consumed in new and
unique ways. Deb did a great job of breaking this down, so please
see her post too.

I could go into more detail with examples, implementation ideas,
etc., but at this time I think it would be more useful to identify
other potential long-term goals, themes, and interesting areas to
explore.

[Jean-Marc Desperrier]

Benjamin Smedberg wrote:
> It seems to me that many of these features are either niche (bittorrent)

bittorrent, a niche ? Probably better handled by a separate application,
but I wouldn't call it a niche.

[Jean-Marc Desperrier]

Matthew Gertner wrote:
> We've been working for over a year on a next-generation web browser,
> packaged as a Firefox extension, so perhaps some of our experiences
> could be of value to this discussion. The key functionality that we have
> added to Firefox includes:
>
> - Authenticated identity (via PKI and digital certificates) inside the
> web browser.

What exactly do you find useful to add, in this regard ? Is it more
about managing it, per site ?

[Benjamin Smedberg]

I'd welcome real market data. But I suspect that community sharing of large
files is and will remain a small market share activity.

--BDS

[Matthew Gertner]

Benjamin Smedberg wrote:
> I'd welcome real market data. But I suspect that community sharing of
> large files is and will remain a small market share activity.

Well I've heard many reports of BitTorrent activity representing 40-60%
of total internet traffic.

[Matthew Gertner]

Robert Sayre wrote:
> The problem with the RDF data model is that it is always possible to
> make a case for it. I think this discussion would be more productive if
> you focused on a concrete example.

I'll start a thread about this is m.d.platform.

I can tell you that my first question
> will be whether it is necessary to identify every node with a URI.
> Nearly everything in Mozilla comes with a base URI, so I'm not sure it's
> necessary past that. Something like Google's BigTable might be good...
> we wouldn't need the large scale distributed aspects of it, of course. I
> don't think we want to build anything ourselves.

Well a URI could be as simple as "mozilla:1", "mozilla:2", etc.

> Some of the networking code might be useful, given the WHAT-WG APIs,
> session restore, and prefs stored on the network. For example, how do
> you detect those wifi firewalls that block all traffic until the user
> signs into a web page?

Like other P2P software I've seen, we act like the network is
unaccessible until the user signs in. Some naive firewalls used to let
you through anyway if you're not using an HTTP/S port, but they seem to
have cottoned on to that.

Matt

[Matthew Gertner]

No, the idea is that you have a single digital identify, managed by the
browser. Right now we use it for our own network but it would be
straightforward to expose it to websites to enable useful things like
single sign on.

Matt

[Ognyan Kulev]

Sherman Dickman wrote:
> Goal: Enable end-users to build a valued asset base
> ------------------------------------------------------------
> * If mail serves as the de facto database for interpersonal
> communications, can Firefox fulfill a similar role for information found
> on the Web?

[...]

One interesting possibility is to handle mailto: handlers in new
window/tab, e.g. when link is mailto:som...@gmail.com. This would be
something like searchplugins, but for turning mailto: to other URL but
it requires providers of services to write such plugins. It could be
used for other schemes besides mailto:, e.g. Atom feeds (distinguished
by MIME type) that are passed to web application. I don't know if such
an idea popped up before. Firefox would become like mini-OS for web
applications :-)

Important question is will it be valuable for large amount of users.

Regards,
ogi

[Gervase Markham]

rudi...@gmail.com wrote:
> We are working with a lot of imagery that our students use for visual
> analysis. This is certainly one area of interactivity that browsers to
> my knowledge have not entered at all. The functionality that I would be
> looking for is simple. So far browser just display images. Period. A
> little zooming functionality here and the capability to roam around in
> a image there. Combine it with some information box that tells you
> something about cursor position and current color value. And you got
> yourself image analysis functionality. Very basic but quite sufficient
> for a lot of purposes.

There are extensions that do some of this (e.g. the Dropper extension
picks out colours) already.

This sort of function sounds fairly domain-specific to me.

GErv

[Gervase Markham]

Alex Graveley wrote:
> What I would love to see is further blurring of the lines between what

> is the web and what is a native application...

>
> To facilitate this, Mozilla can work to educate developers on how to
> write better application code that can work without network access, or
> that can behave more like a native application. By adding application
> interchange interfaces for accomplishing things like DnD and copy/paste
> (either from the OS or another web site) the lines signifying where the
> web starts and ends further evaporates.

...as, if you are not very careful, does the user's security and privacy.

Gerv

[Gervase Markham]

Jon Smirl wrote:
> Are things set up now so that PDF or ODF could be a full-featured
> dynamically installable module (not a plugin)? We have to careful not
> to increase the memory footprint on limited machines. I'd like to see
> SVG become a module too now that the hooks that it needs are known.

ODF can be supported pretty well using an XSLT transform. There's an
extension which does it already:
https://addons.mozilla.org/firefox/1888
And it's only 8K.

My view is that this function should be built into Firefox 3. 200+
million extra ODF viewers around the world would certainly help to drive
adoption. And this goes to the Mozilla Foundation's overarching mission
of promoting choice and innovation.

Gerv

[Gervase Markham]

Benjamin Smedberg wrote:
> It seems to me that many of these features are either niche (bittorrent)

I think Bittorrent has moved out of its niche. Most reports seem to
indicate that it's over 50% of all Internet traffic right now. OK, so
this could be 3 warez dudez exchanging a lot of movies with each other,
but it seems more likely that peer-to-peer distribution is going mainstream.

Sadly, a lot of what's exchanged violates copyright, and that illegality
rubs off onto the BT protocol itself. Building BT into Firefox, and
encouraging legitimate uses of it, would help to move the Internet away
from broadcast and towards collaboration, and to reduce everyone's
bandwidth bills (including ours).

If AllPeers are planning to make their BT implementation free software,
that would be fantastic.

Gerv

[Axel Hecht]

I just read an article about ODF on my trip to Toronto. It seems that
the ODF specification is somewhat limited, making the document format
itself somewhat ambiguous. That at least impacts table formulars, I'm
not sure about other parts.
In addition, even those applications with native support for ODF
disagree on the actual layout to some degree.

Given that, I don't think that the XSLT solution is going to provide a
'ODF viewer'. Maybe something like an 'outline'. As sweet showing ODF in
the browser (and more so mail, IMHO) would be, we should be clear about
the expectations here, otherwise we may end up hurting both us and ODF.

In cases where OpenOffice is installed, a real plugin may be better still.

Axel

[Peter Lairo]

Please don't succumb to the "Perfect solution fallacy"(1). Please add
ODF support, and then improve it from there. Only 8 kibi is an awesomely
small price for such a great benefit.

(1) http://en.wikipedia.org/wiki/Perfect_solution_fallacy

> In cases where OpenOffice is installed, a real plugin may be better still.

And when OpenOffice is *not* installed, we need native ODF support.
--
Regards,

Peter Lairo

Lame attempt to get rich: http://www.lairo.com/donations.html

[Robert Strong]

Agreed that we shouldn't succumb to the "Perfect solution fallacy" but I
don't believe that applies to Axel's statement about setting
expectations appropriately.

-Robert

[Mike Beltzner]

That figure represents the proportion of packets traversing the
"tubes" which are being transmitted using BitTorrent, not the
proportion of activities on the web that are making use of
BitTorrent. The data I've seen shows that while there's a small
proportion of web users who are leveraging BitTorrent (>10%) those
users are using it daily and for large files, explaining the 40-60%
bandwidth use.

I do think BitTorrent is a valuable resource to have, and forsee it
being legitimized and used more and more by mainstream content
distributors to defray the costs of hosting and providing large media
files, but I don't think we should overstate how useful adding native
support for BitTorrent would be for the global audience. The
BitTorrent using audience are also largely finicky about their
clients (cf: uTorrent or Azeureus! Qui es muy macho?!) and I
sometimes wonder if we'd be willing to provide enough functionality
to really satisfy them.

A better direction for inquiry for the data gathering activities to
take would be, I think, to get a sense of the proportion of internet
users who are using their web browsers (or other apps) to download
(legitimately or not) large media files. We have a lot of anecdotal
evidence of this happening more and more because -- well -- we all
live on the web, but it would be good to see what the 95% of the
world who isn't us is doing, too. :)

cheers,
mike

[Aaron Leventhal]

Interesting.

The only thing about this approach (or any approach, really)
is that some work would need to be done to ensure that the
transformed content retains accessibility information.

Accessibility is very important to some of the big backers
of ODF -- it's a key issue in the state of MA. Uptake of ODF
depends on high quality accessibility.

- Aaron

[Gervase Markham]

Axel Hecht wrote:
> I just read an article about ODF on my trip to Toronto. It seems that
> the ODF specification is somewhat limited, making the document format
> itself somewhat ambiguous.

Did they provide any concrete examples?

> That at least impacts table formulars, I'm
> not sure about other parts.

You mean formulas in spreadsheets, I think. That was deliberately
excluded from the original spec; there's now an effort to work on it.
http://www.dwheeler.com/openformula/

> In addition, even those applications with native support for ODF
> disagree on the actual layout to some degree.

The same is true for HTML. Does that mean an HTML viewer is useless? :-)

> Given that, I don't think that the XSLT solution is going to provide a
> 'ODF viewer'. Maybe something like an 'outline'. As sweet showing ODF in
> the browser (and more so mail, IMHO) would be, we should be clear about
> the expectations here, otherwise we may end up hurting both us and ODF.

I don't think anyone expects our rendering of everything to match
OpenOffice.org's exactly. It's a viewer. People use Google's PDF or
Word-to-HTML views, and they are nothing like the original.

But I bet 90% of documents that people author are pretty simple. I know
that if I write a document in ODF and export it to RTF to send by mail,
it normally looks exactly the same. And the RTF spec is at least ten
years old. Not everyone uses the complex features.

Gerv

[Gervase Markham]

Aaron Leventhal wrote:
> The only thing about this approach (or any approach, really) is that
> some work would need to be done to ensure that the transformed content
> retains accessibility information.

That's a very good point, and you should email the authors of the plugin
and make it.

> Accessibility is very important to some of the big backers of ODF --
> it's a key issue in the state of MA. Uptake of ODF depends on high
> quality accessibility.

Absolutely.

Gerv

[Gervase Markham]

Mike Beltzner wrote:
> I do think BitTorrent is a valuable resource to have, and forsee it
> being legitimized and used more and more by mainstream content
> distributors to defray the costs of hosting and providing large media
> files, but I don't think we should overstate how useful adding native
> support for BitTorrent would be for the global audience. The BitTorrent
> using audience are also largely finicky about their clients (cf:
> uTorrent or Azeureus! Qui es muy macho?!) and I sometimes wonder if we'd
> be willing to provide enough functionality to really satisfy them.

But I think we'd be competing against nonconsumption. That is, the
people who would use Firefox for downloading something over Bittorrent
would be people who would otherwise click the "HTTP download" link, but
are happy to click a different one (or the site automatically serves
them a different one based on UA) because they know it helps other
people out.

They will expect (and we should give them) a UI almost exactly like HTTP
download - i.e. entry in the DL manager, progress bar, rate meter etc.
Almost all the fiddly settings that the cognoscenti love will be
defaulted and not exposed in the UI - outgoing uses up to 50% of
bandwidth, you disconnect once you've uploaded 150% of downloaded
amount, or whatever.

Gerv

[Mike Shaver]

On 8/18/06, Gervase Markham <ge...@mozilla.org> wrote:
> But I bet 90% of documents that people author are pretty simple. I know
> that if I write a document in ODF and export it to RTF to send by mail,
> it normally looks exactly the same. And the RTF spec is at least ten
> years old. Not everyone uses the complex features.

Perhaps off-topic, but then why not just use RTF (or, for most of the
documents _I_ get as Word/ODT/etc., good old plaintext) instead of
entraining all of the ODF requirements?

Mike

[Mike Shaver]

On 8/18/06, Gervase Markham <ge...@mozilla.org> wrote:

> They will expect (and we should give them) a UI almost exactly like HTTP
> download - i.e. entry in the DL manager, progress bar, rate meter etc.
> Almost all the fiddly settings that the cognoscenti love will be
> defaulted and not exposed in the UI - outgoing uses up to 50% of
> bandwidth, you disconnect once you've uploaded 150% of downloaded
> amount, or whatever.

I'm approached about every 3 months by someone or some company who are
all excited about providing that capability, but when I ask them what
support they need in terms of hooks or changes to our download model,
I get tumbleweeds and the sound of wind blowing across the great
plains of my inbox.

The Missouri principle should guide us here: show an extension that
provides an approachable and robust user experience for virtuous P2P
filesharing, which not all of us are convinced is straightforward in
this world of NAT and campus firewalls and suchlike, and we can have a
meaningful discussion. Less conjecture, more strict warnings in the
JS console!

Mike

[Benjamin Smedberg]

Gervase Markham wrote:

> They will expect (and we should give them) a UI almost exactly like HTTP
> download - i.e. entry in the DL manager, progress bar, rate meter etc.
> Almost all the fiddly settings that the cognoscenti love will be
> defaulted and not exposed in the UI - outgoing uses up to 50% of
> bandwidth, you disconnect once you've uploaded 150% of downloaded
> amount, or whatever.

The great problem I see with P2P network protocols is that users won't
expect, when they click a "download" link, to have any upload bandwidth
taken; I might even consider that a malware-like behavior (some people still
pay for bandwidth). I don't think that we can allow any upload without
informed consent by the user.

--BDS

[Gervase Markham]

Mike Shaver wrote:
> Perhaps off-topic, but then why not just use RTF (or, for most of the
> documents _I_ get as Word/ODT/etc., good old plaintext) instead of
> entraining all of the ODF requirements?

Because I can never actually know whether or when I'll need a spiffy
feature.

I prefer to write documents as ODF (giving myself the potential of using
that full power if necessary) and then, if I need to mail them to people
who don't have ODF viewers, converting them and checking the output to
make sure it's readable before sending.

Of course, if Firefox had ODF viewing support, I could just email the
ODF to an awful lot more people... ;-)

Gerv

[Gervase Markham]

Mike Shaver wrote:
> I'm approached about every 3 months by someone or some company who are
> all excited about providing that capability, but when I ask them what
> support they need in terms of hooks or changes to our download model,
> I get tumbleweeds and the sound of wind blowing across the great
> plains of my inbox.

Fair enough. I'm not asking that we do a bunch of work in support of
someone else's pipedream.

However, AllPeers have integrated Bittorrent (how, I'm not sure) and say
they are planning to make their code free software later in the year. So
we will have something to work with.

> The Missouri principle

Googling only provides references to slave-related agreements in the US
in the 1820s. Are you being particularly erudite, or have I missed
something?

Gerv

[Gervase Markham]

Benjamin Smedberg wrote:
> The great problem I see with P2P network protocols is that users won't
> expect, when they click a "download" link, to have any upload bandwidth
> taken; I might even consider that a malware-like behavior (some people
> still pay for bandwidth). I don't think that we can allow any upload
> without informed consent by the user.

I guess we could warn them first time.

Who still pays for upload bandwidth in this way? All the tariffs I know
of in the UK restrict your download bandwidth (10GB per month, etc. etc).

Gerv

[Deb Richardson]

On 8/18/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>
>
> The great problem I see with P2P network protocols is that users won't
> expect, when they click a "download" link, to have any upload bandwidth
> taken; I might even consider that a malware-like behavior (some people
> still
> pay for bandwidth). I don't think that we can allow any upload without
> informed consent by the user.

I very strongly agree with this point. Peer to peer networks have very poor
reputations in a lot of situations (Napster, Kazaa, etc), so the majority of
normal people either a) have no idea what a P2P network is, b) have no way
to know the difference between Kazaa and and Bittorrent, and/or c) think
that P2P networks are bad things (the realm of thieves, malware writers, and
pirates (yarr)).

Honestly, until we have some extremely solid market research about the
actual demand for P2P networking and the general market view of those sorts
of systems, I'm not sure we should saddle our products with that
questionable-reputation-through-association while trying to fill a need for
what may be a very small percentage of our current or potential users.

~ deb

[john....@gmail.com]

my own two cents are that this should go pretty much like search (and
now RSS reading) does: we should open up the download manager for
pluggable protocols, and talk about what protocols get included in the
distribution at some point down the line. have been talking with cbeard
about this for about a year; have talked with the BitTorrent folks,
etc.

[Frank Hecker]

Gervase Markham wrote:
>> The Missouri principle
>
> Googling only provides references to slave-related agreements in the US
> in the 1820s. Are you being particularly erudite, or have I missed
> something?

http://www.sos.mo.gov/archives/history/slogan.asp

Frank

--
Frank Hecker
hec...@mozillafoundation.org

[Axel Hecht]

Assuming they use Firefox to read mail. Or that we start shipping
Thunderbird with XSLT on. What does Thunderbird do for, say pdf?

Anyone who actually tried that extension? I only read the description of
it and started wondering if we could fix it. But I didn't actually find
pagination info prominently in the ODF specs, so I don't know. If I
write paginated docs and they come out without pagination (like the
extension claims, I didn't test), that'd be not-so-good.

One thing that we should aim at is to have a hook to actually kick off
OOo if it is installer, maybe even only if it's already running.

Axel

[Blake Kaplan]

Mike Shaver <mike....@gmail.com> wrote:
> Perhaps off-topic, but then why not just use RTF (or, for most of the
> documents _I_ get as Word/ODT/etc., good old plaintext) instead of
> entraining all of the ODF requirements?

Because when you say that, my first thought is rickg's CRtfDTD. Need I
say more? :-)
--
Blake Kaplan

[Robert Sayre]

Deb Richardson wrote:
> On 8/18/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>>
>>
>> The great problem I see with P2P network protocols
>

> I very strongly agree with this point. Peer to peer networks have very
> poor reputations

I think these protocols become interesting to Mozilla products if the
host OS provides a service that implements it. Vista and OS X 10.5 will
have shared RSS enclosure caches. That is usually HTTP these days, but
BitTorrent URIs are becoming more common.

-Rob

[Blake Kaplan]

Mike Shaver <mike....@gmail.com> wrote:
> Perhaps off-topic, but then why not just use RTF (or, for most of the
> documents _I_ get as Word/ODT/etc., good old plaintext) instead of
> entraining all of the ODF requirements?

We even have rickg's old RDF tokenizer/parser in CVS history! We could
just bring that back and... profit?

I guess ODF does have the advantage that it's already XML + CSS.
--
Blake Kaplan

[Gervase Markham]

Axel Hecht wrote:
> Assuming they use Firefox to read mail.

No; it just has to register itself as the system handler for .odf and
friends, assuming there isn't one registered already.

> Anyone who actually tried that extension? I only read the description of
> it and started wondering if we could fix it. But I didn't actually find
> pagination info prominently in the ODF specs, so I don't know. If I
> write paginated docs and they come out without pagination (like the
> extension claims, I didn't test), that'd be not-so-good.

I've tried 0.1; it worked well. I haven't tried 0.2 yet.

Gerv

[Gervase Markham]

Deb Richardson wrote:
> Honestly, until we have some extremely solid market research about the
> actual demand for P2P networking and the general market view of those sorts
> of systems, I'm not sure we should saddle our products with that
> questionable-reputation-through-association while trying to fill a need for
> what may be a very small percentage of our current or potential users.

It doesn't seem to have done Opera any harm... at least, not that
anyone's pointed out.

Gerv

[pascal chevrel]

Le 21/08/2006 17:58, Gervase Markham a ecrit :

The right question might be "did it do any good to Opera?" ;)

pascal

[beltzner]

On 7/28/06, Sherman Dickman <she...@mozilla.com> wrote:
> I would like to get everyone's thoughts on potential long-term
> themes, goals, questions that would be interesting to answer, and
> areas where it would be useful to have better data. Rather than
> focusing on individual features, I think it would be helpful to keep

Looking back at the original mandate of Sherman's call-out, I realize
that we've gotten into ratholes of investigating individual features.
I believe what we should be doing is identifying the areas which we
know we're interested in getting more contextual data on in order to
make informed decisions. As such, I propose that we reframe our
suggestions so that they include:

- the name of the theme, just to act as a label
- why the investigation is worth the time and effort
- what the scope of investigation should be (long term? immediate?)
- the questions that need investigating

Here's a few to get us started:

THEME: Just what are our users doing with our product?
------------------------------------------------
Why it's important: The Firefox charter states that the browser should
be serving the majority audience in their online tasks, but there is
no recent data (especially since the Web 2.0 explosion) showing what
users are actually doing online. It's easy to make assumptions based
on personal and peer group experience, but those results skew to our
own user bases.

Scope: immediate & long-term

Questions to investigate:
- who are our users, and how much are they doing online?
- what's the average user:browser profile ratio?
- what sort of tasks are they doing online?
- what do they want to be able to do more of online?
- what is the relative usage per type of online task?
- what kind of websites do they visit (brochureware, applications,
collaborative/community?)
- how many unique websites do they visit?
- what percentage of time is spent visiting new websites as opposed
to returning to previously viewed sites?

THEME: What is the competitive landscape for web browsers?
----------------------------------------------------------
Why it's important: The choice our users will have to make is, "why
Firefox?", so we should understand the factors on which they will be
basing that decision. Getting into feature wars is uninteresting, but
understanding long term competitive strategies is a must.

Scope: immediate & long-term

Questions to answer:
- what is the emerging strategy of our competitors?
- how does the strategy of OS vendors affect the web browser?

THEME: Improving a user's security while online.
------------------------------------------------
Why it's important: Identity theft and phishing are getting a lot of
attention in the technical press, and last year saw several studies
showing that SSL indicators weren't being properly interpreted by
users.

Scope: immediate

Questions to investigate:
- what are the emerging standards for website authentication?
- what are the current levels of awareness about online scams?
- why are current trust/authentication indicators failing?
- what are the primary vectors of attack for web scams?
- what are the primary vectors of attack for malware?

THEME: WS-* SOAs, remixable APIs and web applications
------------------------------------------------------
Why it's important: Over the past year the web has become more and
more about online applications and services, and recently a lot of
remixing of those services has heralded the promise of the "Service
Oriented Architecture". Understanding how service remixing, especially
user-generated, will affect the web will keep us prepared for the next
paradigm shift.

Scope: long-term

Questions to investigate:
- with more available APIs and light- and heavy-weight service
oriented architectures, how popular will service remixing become?
- what are the predicted effects on various Firefox stakeholders?
- what are the predicted effects on web content creators?

THEME: Making use of rich metadata
----------------------------------
Why it's important: More and more metadata is available (Microformats,
RDF, RDF/A, CC info, attributions, etc) yet systems aren't taking
advantage of it. Being able to react intelligently to this metadata
would make the web browser a more personal and useful tool for users.

Scope: immediate and long-term

Questions to investigate:
- what are the most frequently occuring kinds of metadata available?
- what other metadata exist, though not in any formal specification?
- in what ways is the browser most frequently considered by users to
be "dumb" when not reacting to metadata?
- what tools exist for leveraging metadata and acting upon it?
- why did the semantic web never take off?
- how does collecting data conflict with privacy concerns?
- what are the emerging standards for metadata handling?

Theme: Making the browser disappear
-----------------------------------
Why it's important: The best kind of tool is one that becomes a
natural extension of the individual. We should aspire to entirely
disappear from the user's conscious view and just be an extension of
their selves.

Scope: immediate

Questions to investigate:
- what are the most common user annoyances with web browsers?
- how do web browsers and web applications conflict in terms of UI?
- where does Firefox interrupt instead of assist common user taskflows?
- what UI/tools/features are not used or needed in the product?

I think that this will end up being a much more actionable set of
research topics; feel free to disagree! I'll keep thinking and
hopefully come up with more later.

cheers,
mike

--
/ mike beltzner / phenomenologist / mozilla corporation /

[Rudi Gens]

> Theme: Making the browser disappear
> -----------------------------------
> Why it's important: The best kind of tool is one that becomes a
> natural extension of the individual. We should aspire to entirely
> disappear from the user's conscious view and just be an extension of
> their selves.
>
> Scope: immediate
>
> Questions to investigate:
> - what are the most common user annoyances with web browsers?
> - how do web browsers and web applications conflict in terms of UI?
> - where does Firefox interrupt instead of assist common user taskflows?
> - what UI/tools/features are not used or needed in the product?

I quite like the idea of common user task flows. That sounds to me like
a very good way of learning about people's web habits. You might want
to consider to solicitate input from the broader user community. Ask
people to come up with their scenarios of work flows that demonstrate
where FF3 could make a difference.

To give you an example I can give you one quite typical scenario that I
run into on a regular basis. You know there is a
conference/workshop/meeting out there and you look for a website with
the details. That is where the scenario starts. What kind of
information do you need? After you figure out this conference is
interesting, you will bookmark it. Looking over the topics you realize
there is something for your colleagues as well. Just sending them the
link is one thing but I normally would print out the page, highlight
the relevant part and put it on their table. No reason why a web
browser should not be able to do this kind of thing (highlight, add a
comment and send it by email). I guess I need to write down when the
conference takes place and when the important deadlines are. Wouldn't
it be nice if I could highlight a date and my browser puts it in my
calendar for me? I like to partcipate in one of the workshops they
offer. Lets write down the contact details of the guy in charge of the
workshops. Or let your browser add that person to your contacts (if it
would be able to do that). What I just found was the first call for
papers. I need to stay on top of changes to get the important
announcements. Being automatically notified would be mighty nice. I
probably want to write down some notes about the paper I intend to
submit. Would be nice if I could attach that in some fashion to the
page.

All these little things can be supported with a number of little
helpers but it would surely nice if you could offer this type of work
flow without leaving your browser. People look for convenience, for
intuitive solutions. You don't need to win over the expert users. They
love the flexibility they have with FF and tailored extensions anyway.
You look for something that appeals to the average user and lets them
chose FF over any of the other browsers.

Hope this makes some kind of sense.

Cheers,
Rudi

[Christian Biesinger]

Mike Shaver wrote:
[bittorrent integration]

> I'm approached about every 3 months by someone or some company who are
> all excited about providing that capability, but when I ask them what
> support they need in terms of hooks or changes to our download model,
> I get tumbleweeds and the sound of wind blowing across the great
> plains of my inbox.

FWIW, I don't believe that any additional hooks are needed. In the
bittorrent bug I outlined how an extension could implement BitTorrent
with the existing APIs. In particular, showing an entry in the download
manager and its progress etc. isn't limited to normal HTTP or similar
downloading.

[Gen Kanai]

Re-starting this thread, Read/Write Web has a pretty interesting post
on the blog regarding "desktop apps vs. browser-based apps."

http://www.readwriteweb.com/archives/
webified_desktop_apps_vs_browser_apps.php

There's an unscientific poll (although with almost 13,000 responses)
with some interesting comments.

http://www.readwriteweb.com/archives/
poll_desktop_browser_apps.php#comments

There are a number of different threads here that I'd like to call
out in relation to our planning for FF 3.

- operating systems becoming more browser-like
- browser-based apps becoming more "application-like"
- the impact of mobile on data availability

A number of the more interesting comments are collated here:

http://www.readwriteweb.com/archives/
readwriteweb_discussion_3-9sept06.php

There's a lot to think about here.

Gen
Mozilla Japan