1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
1. A definite improvement over the previous version I saw.
2. Contains some interesting ideas:
Features:
> Multiple content views
> Display of an XML file as a frame floating in the content view
> Customizability
I like the ability to drag colors from the color selector to a window.
> Interface
. Much attention paid to producing a user-friendly result here.
. "Everything Windows explorer is and more"
. Simplicity of available operations
. Providing as much useful information as possible from a given screen, without
overloading the user (e.g. thumbnails).
. I like the (debated) user levels, but wish their differences were known.
Design:
Implementation:
> Code is survivably good - not wonderful, but not procmail
> Using XML allows easy integration of web data sources, etc.
3. Has some drawbacks:
Features:
> Interface
. Value of the panel is questionable
. Double-click vs. single click needs explanation/exploration
. More information on what the new user
. The "file operations" area of the interface is not explored very well and
is very vague.
Design:
> Is basically a collection of intertwined widgets, rather than
a data-oriented class hierarchy.
> No abstraction of common patterns
> Extensibility virtually non-existent
> Generally poor.
Example - instead of instantiating the a certain class with a well-known
interface when a particular view is requested, MultiView is used
with a number of set_*_view() functions that are hardcoded to display
certain views.
Example - The iconview has special cases for the vault in its metadata-reading code.
Example - There is only one application-level class that is ever derived from (IconView),
out of the thirty or fourty such classes present.
Implementation:
> Performance is poor (possibly due to use of AA canvas)
"It has to be faster if you are going to get people to use this"
> Uses Gtk--
. In constant flux
. Relatively high resource demands
> Somewhat buggy
> Using XML - may not always be appropriate, has performance implications in the
current usage situations, what about gnome_metadata.
> Doesn't use gnome-vfs
4. My conclusions
gnomad is very focused on the user interface, and looks promising for producing a good
user experience.
The patterns that pieces of gnomad fit would allow for easy integration into Nautilus.
I recommend that that an assessment be made of features still needed from Nautilus, and
that we turn the various views of Gnomad into Bonobo controls for use in Nautilus.
Appendix A: What Nautilus is
The generic pattern of content view/meta views/available operations occurs in a wide
variety of situations. The Windows web-browser interface uses the basics of this, but
does not exploit it to its full potential.
Nautilus is a data shell that uses Bonobo components to present the best possible user
interface for a given piece of data. When navigation to a particular URL is requested by
a view (either the main content view or one of the meta views), Nautilus determines what
content view and meta views should be displayed, based on the requested URL, the
referring URL, the content type of the requested URL, and application configuration.
This allows a standard yet appropriate interface to be provided for an infinite variety
of data types.
http://people.redhat.com/sopwith/h3.gif contains a screenshot of the help browser
prototype that produced the idea for Nautilus. This window follows the content
view+meta views pattern that Nautilus supports.
Based on analysis of gnomad, features that Nautilus design still needs:
More thorough examination of what data-related elements the user interface
should incorporate (especially in the areas of toolbars/menus).
Ways of displaying meta views besides as tabs in a notebook.
Multiple content views.
Passing RDF-like tree from content to meta views, instead of just the URL.
Other features that I had been planning to add:
Ability for displayed views to modify menus/toolbars
(just need to make use of GnomeUIHandler, I think).
Finish implementation of the whole URL -> set of views code.
Finish implementation period. :)
Appendix B: Bugs
Remove semicolon from end of music_view.cpp:115 (still doesn't work, oh well).
|
