Tuesday, September 23, 2003
About a year ago Paper Airplane had to drop a
number of powerful features due to time and not having
enough developers. Here are some of the features that were
dropped; maybe someone will be interested in working on them:
Browsers shouldn't just have editors, they should
have powerful editors
One of the original ideas behind Paper Airplane was a
thought experiment: what would it look like if you
merged web browsers and office productivity suites
together? The idea was that browsers shouldn't just
have editors, they should have powerful editors. It
should feel fluid and like magic. You would never
have to context-switch out of the browser to start
writing; they would be seamlessly integrated. Saving
a page would feel just like working with a WikiWiki;
you simply hit Save and the page gets saved into the
peer network onto your site, and you hit Edit on a
page and it loads in-place into the browser, with the
chrome changing to the editor. Hoang Dinh, Paper
Airplane's resident UI wizard, and I mocked up a unique
editor. It combined Microsoft's Mac Office X
Formatting Palette concept,
Mozilla's Sidebar, and the ease of use and integration
of GobeProductive.
The Formatting Palette would move into Mozilla's
Sidebar, and would context-switch based on what object
was selected on the right-hand side while the user was
editing; never again would you have to dig through
endless pull-down menus and dialog boxes to figure out
how to change some visual feature of your document.
User's could insert and edit spreadsheets,
presentations, and text. Unlike normal HTML, things
could be exact positioned and could be moved around
easily with the mouse, and text would flow around the
objects in a simple, powerful way. The editor would
save the document in OpenOffice's XML format. Since
this was an Internet, community word-processor,
collaboration would be built in by simply being able
to drop notes into a document; a note would
automatically be a threaded-discussion attached to a
specific location in the document; no server-side
scripts to setup or servers to run, since this is a
P2P network. Here is a screenshot of the editor
mockup.
Here is what a note/threaded discussion dropped in
looked like. This would also include the AutoLink feature, familiar
from WikiWiki's; see a screenshot of this feature.
Semantic Web, Take One
Once we have a powerful editor built into the browser,
we can then take a stab at the Semantic Web in a
unique way. I see two chief usability impediments to
the Semantic Web. First, how to you get users to
enter that metadata? Most user's don't even know what
metadata is. Second, how do you leverage this
metadata in a way that is actually useful? I think
one possible solution to the first problem is
straightforward; many user's actually use templates
when they create documents with Microsoft Office, such
as a template for a resume or one for a memo. They
click on little fields in the template and enter their
values, such as clicking on the field that says
"Education". Templates just throw this information
away now, but why can't they be saving this metadata
in the document when it is saved? When a user clicks
on the field that says "Position", why can't we simply
save in the file that this field is a Position field?
If we do this for all the fields in the template, then
the user is entering metadata without even knowing it;
this would effectively then transform Paper Airplane
into something more like Lotus Notes, which had a
concept called databases. I don't have a solution to
the second problem yet; I think one of the killer apps
for all this semantic metadata is search, but how do
you present this extra search capability without
overwhelming users with query languages and too many
knobs?
Security, Usability, and Decentralization. Now
that's Good Looking.
A long-term issue is being able to solve Zooko's
Challenge, which some say is impossible. For full
details see the WikiWiki page for DisDNS, which is
the name of the distributed DNS in the P2P Sockets
system. If this were solved it would
torpedo Verisign, and make things like distributing
the white-pages of VoIP apps possible.
Ordinary People Should be able to Reach Millions of
People
One big idea behind Paper Airplane is that ordinary
people should be able to create online communities
without technical knowledge, servers, or paying money.
These online communities/sites should be able to
scale and reach potentially millions of people. How
do you achieve this, especially in a way that is
seamless and hopefully invisible to the user? How can
you give each web community the same power as Akamai?
One idea was something called distributed storage,
where the user's site is broken into hundreds of
pieces and seamlessly stored on other user's
machines, similar to what MNet or Freenet does. Unfortunately, the reliability, security,
and motivation issues made it hard to figure out how
to do this.
number of powerful features due to time and not having
enough developers. Here are some of the features that were
dropped; maybe someone will be interested in working on them:
Browsers shouldn't just have editors, they should
have powerful editors
One of the original ideas behind Paper Airplane was a
thought experiment: what would it look like if you
merged web browsers and office productivity suites
together? The idea was that browsers shouldn't just
have editors, they should have powerful editors. It
should feel fluid and like magic. You would never
have to context-switch out of the browser to start
writing; they would be seamlessly integrated. Saving
a page would feel just like working with a WikiWiki;
you simply hit Save and the page gets saved into the
peer network onto your site, and you hit Edit on a
page and it loads in-place into the browser, with the
chrome changing to the editor. Hoang Dinh, Paper
Airplane's resident UI wizard, and I mocked up a unique
editor. It combined Microsoft's Mac Office X
Formatting Palette concept,
Mozilla's Sidebar, and the ease of use and integration
of GobeProductive.
The Formatting Palette would move into Mozilla's
Sidebar, and would context-switch based on what object
was selected on the right-hand side while the user was
editing; never again would you have to dig through
endless pull-down menus and dialog boxes to figure out
how to change some visual feature of your document.
User's could insert and edit spreadsheets,
presentations, and text. Unlike normal HTML, things
could be exact positioned and could be moved around
easily with the mouse, and text would flow around the
objects in a simple, powerful way. The editor would
save the document in OpenOffice's XML format. Since
this was an Internet, community word-processor,
collaboration would be built in by simply being able
to drop notes into a document; a note would
automatically be a threaded-discussion attached to a
specific location in the document; no server-side
scripts to setup or servers to run, since this is a
P2P network. Here is a screenshot of the editor
mockup.
Here is what a note/threaded discussion dropped in
looked like. This would also include the AutoLink feature, familiar
from WikiWiki's; see a screenshot of this feature.
Semantic Web, Take One
Once we have a powerful editor built into the browser,
we can then take a stab at the Semantic Web in a
unique way. I see two chief usability impediments to
the Semantic Web. First, how to you get users to
enter that metadata? Most user's don't even know what
metadata is. Second, how do you leverage this
metadata in a way that is actually useful? I think
one possible solution to the first problem is
straightforward; many user's actually use templates
when they create documents with Microsoft Office, such
as a template for a resume or one for a memo. They
click on little fields in the template and enter their
values, such as clicking on the field that says
"Education". Templates just throw this information
away now, but why can't they be saving this metadata
in the document when it is saved? When a user clicks
on the field that says "Position", why can't we simply
save in the file that this field is a Position field?
If we do this for all the fields in the template, then
the user is entering metadata without even knowing it;
this would effectively then transform Paper Airplane
into something more like Lotus Notes, which had a
concept called databases. I don't have a solution to
the second problem yet; I think one of the killer apps
for all this semantic metadata is search, but how do
you present this extra search capability without
overwhelming users with query languages and too many
knobs?
Security, Usability, and Decentralization. Now
that's Good Looking.
A long-term issue is being able to solve Zooko's
Challenge, which some say is impossible. For full
details see the WikiWiki page for DisDNS, which is
the name of the distributed DNS in the P2P Sockets
system. If this were solved it would
torpedo Verisign, and make things like distributing
the white-pages of VoIP apps possible.
Ordinary People Should be able to Reach Millions of
People
One big idea behind Paper Airplane is that ordinary
people should be able to create online communities
without technical knowledge, servers, or paying money.
These online communities/sites should be able to
scale and reach potentially millions of people. How
do you achieve this, especially in a way that is
seamless and hopefully invisible to the user? How can
you give each web community the same power as Akamai?
One idea was something called distributed storage,
where the user's site is broken into hundreds of
pieces and seamlessly stored on other user's
machines, similar to what MNet or Freenet does. Unfortunately, the reliability, security,
and motivation issues made it hard to figure out how
to do this.
Subscribe to Posts [Atom]
