114 |
it looks natural and integrated, because the applitude |
it looks natural and integrated, because the applitude |
115 |
*always* uses this mechanism to show additional information. |
*always* uses this mechanism to show additional information. |
116 |
|
|
117 |
|
--------------------------------------------------------------------------- |
118 |
|
|
119 |
|
Ok, I think basically that's the view system. Then, |
120 |
|
of course, you have menus with commands, which can be |
121 |
|
tailor-made to an applitude ("make appointment," something |
122 |
|
like that). Users can create their own menus; they're |
123 |
|
just some RDF structure shown in a special way (always |
124 |
|
present on the screen or so). |
125 |
|
|
126 |
|
Also, there needs to be a good way to store and organize |
127 |
|
view presets: E.g., to create a money view, you'd select |
128 |
|
"View showing text below node" or something, select the |
129 |
|
RDF property to show (``money:cost``), select small |
130 |
|
text size and red color. Then you'd put this |
131 |
|
view-with-parameters into a "view" menu as "Expenses," easily |
132 |
|
showable and hidable. |
133 |
|
|
134 |
|
(Note BTW that I use "menu" to include things containing toggles-- |
135 |
|
we have lots of those, switching particular RDF properties |
136 |
|
on and off for example.) |
137 |
|
|
138 |
|
Finally, you want menus to be context-dependent very likely-- |
139 |
|
i.e., when you're scheduling, you want to see the menu with |
140 |
|
"Make appointments" readily, and so on. |
141 |
|
|
142 |
|
Then, basically, I think that's it. |