[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a web-browser UI concept
|
From: |
Graham J Lee |
|
Subject: |
Re: a web-browser UI concept |
|
Date: |
Thu, 1 Mar 2007 14:52:04 +0000 |
On 1 Mar 2007, at 14:24, Camille Bourgoin wrote:
On 2007-03-01 14:01:55 +0100 Graham J Lee <leeg@thaesofereode.info>
wrote:
On 1 Mar 2007, at 12:12, Camille Bourgoin wrote:
Hello !
This morning, in my bath, I think of a user-interface concept for a
web-browser. I wrote a paper about it. Maybe is it bad, maybe it can
be useful for somebody.
[...]
Not a specific comment about your own design but I find it hard
to marry the
concept of tabbed browsers with a document-based
design...document-based
apps should have one (or more) windows per document, whereas tabs
gives you
one or more documents per window.
Yes. You are right.
On the other hand, people tend to view
web pages at something close to the full size of their screen so
a suitably
flexible tab system (like OmniWeb 5.x) can be a benefit to screen-
space
organisation.
You are right. Today tabs are necessery. Maybe the concept of file (au
sens de "classeur", je ne sais pas si le terme "file" traduit très
bien cette idée) can combine the tab and the document-oriented app
... A "file" (un classeur) is not a document. It's a space (a window)
who gather document together.
As far as the NSDocument architecture is concerned, the way current
browsers work a document/classeur would be the page currently visible
in a tab _and_ the history of that tab, I think. I also think that's
a confusing way of doing things...unless I'm going back to the page I
was only just reading, it causes great mental anguish to try and
determine exactly what URI I will be looking at when I next hit the
back button. I end up not using the back button and going for the
history menu instead...so a history inspector would be more useful
and the "document" in the document view could just be the currently-
visible page.
This is the reason why :
1) the toolbar is separated from the document window. When you gather
two documents together and the toolbar is integrated with the document
: two toolbars (two window) became one toolbar => two documents became
one document. This is an application oriented application.
With the model in my mind (not very useful, I know ;) ) the document
who are gather with another one, is just "behind" the other document.
I get this, and I think it's how most tabbed browsers work. As I
say, multiple documents per window...the user can't really cope with
multiple documents at the same time though so only one is being
interacted with (and usually is the only one visible).
2) this is the reason why the Edit action act only on the document
who are selected. When you click on another document (even if it is
gather with it), you return to the navigation mode. Go back to the
edited document, and you are in edition mode etc. I don't know if it
is possible :(
- (BOOL)[MyNSDocumentSubclass isBeingEdited];
- (void)[MyNSDocumentSubclass setBeingEdited: (BOOL)editing];
...unless I'm missing something subtle? Then when a new document
becomes the 'active' document, the View draws it in editing/viewing
mode as appropriate.
3) back and forward are seperated from documents because they are
your hands who turn the pages. And we haven't 10 hands ;)
True, but we often don't have more than one book open ;-)
Thank you for your comments ! They are very very interesting.
I hope my franchglish is understandable !
Ja, es ist sehr gut.
The article is in french, but the sketches are in english (I'm not
very good in english, sorry :( )
Nous sommes une bonne équipe, parce que je ne comprends pas un mot de
français ;-).
Ce projet serait-il un refuge de francophone ?? Encore merci pour
toutes tes remarques. J'espère y avoir répondues correctement.
Oui, il y a un ou deux francophones ici. But I'm only slightly one
of them ;-)
Graham.