Re: Three Point Zero - Idea Mockups
- From: Nigel Tao <nigel tao myrealbox com>
- To: desktop-devel-list gnome org
- Subject: Re: Three Point Zero - Idea Mockups
- Date: Wed, 25 May 2005 23:51:48 +1000
> - I don't think dropping all directory structures is a good idea. What
> would you e.g. do with my Projects folder? "Projects" in se (autotooled
> etc) are based on structured files and directories, you can't just "tag"
> them. There are only some specific directories you could drop and use
> tagging instead (like Documents, Images, Music,...).
Admittedly, the storage idea breaks down when you have to have explicit
locations or file names (e.g. programming or web site design). Perhaps
"files" could be either implicitly (automagically) stored (when I
download my mail, I don't need to know what file path it lives at - I
just need to tag it and be able to retrieve it), or explicitly stored
(where the user designates a location like ~/foo/bar/filename.py, and it
automatically picks up the tags "foo", "bar", "filename" and "type:py" -
moving the file will change its tags).
Maybe this would work, maybe it won't.
> - In the create menu: if I got both Inkscape and Gimp installed, what
> will be started when I choose "Illustration"?
You would get a new illustration - you wouldn't know what "application"
was handling it. Architecturally, it could work like Eclipse's
plug-in / extension mechanism - there'd be a "SVG" mimetype and
installed "applications" would provide UI to work with SVGs and fill out
the menus/toolbars/palettes/whatnots.
Note: this is all hypothetical (and a non-trivial amount of hacking) at
the moment. This may work brilliantly, or it may all fall over in a
flaming heap.
> - The long running tasks: great idea, but this will need a good
> way/standard to talk between processes (CDIS? ;-)). In the end, it won't
> be the panel/panel applet that will be leeching a torrent, it's an
> application that will do this, even if this application is not visible
> to the user.
What I have in mind is similar to how different apps currently share the
Notification Area UI space. But remember that my mockups are app-less.
> - On the use of the "Windows" key: notice not everyone has got this key
> (Mac users I guess, people with a nice old keyboard, or maybe
> die-hard-Windows-haters who bought a special keyboard).
Mac users have an command/apple key. IBM keyboards apparently don't. I
was wondering why Super seemed (IMHO) under-used as a modifier. I can't
even bind it to things when I do have the key.
http://bugzilla.gnome.org/show_bug.cgi?id=165343
With regards to my mockups, perhaps <Control>-<Alt> could be used
instead of <Super>, similar to the suggestions at
http://live.gnome.org/PowerUserTools
> - When you write "I followed the '439 messages' link, results are in the
> same window" -> this means one application must be able to diplay a lot
> of different data formats, which is (IMHO) a bad thing.
It's not one application, the applications are "invisible" or ego-less.
They just happen to share a window (and back/forward history).
Currently, my mail client, my RSS reader, and my browser are all
different apps, and they sometimes behave slightly differently when I
left click or middle click on a link - I have to interrupt my flow to
remember what app I'm running to remember which button to click to "open
the link in another window/tab, but keep this one around too". This is
a cognitive load which I think is removable.
> Woul'nt it be
> better to start the user's email client (evo) with a auto-applied search
> filter like "from: jeff", so the user sees all jeff's emails the same
> way as his normal non-filtered inbox.
But I don't want just Jeff's emails. I want his mail, IMs, IRCs, and
blog posts. And possibly photos of Jeff, things I've downloaded from
his website, documents that I've co-authored with him, etc. etc. These
sort of searches are cross-application. Arguably, Beagle/BEST will do
this for you, but I reckon that we can remove the whole artificiality of
separate "applications" or modes as well.
> - On mouse usage: when the right mouse button defaults to dragging the
> window, context-specific popup menu's (as used now) won't be possible
I should have clarified my suggestion: right-click is context menu,
right-drag is move window. Just like currently, in nautilus, it
differentiates between left-click and left-drag (at least it does the
way I have it, with the "Single click to activate items" preference set
- all double clicking is bad (and should be removed), in my book, but
I'll leave the flame^Wdiscussion for another time).
Thanks for listening,
Nigel.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]