A collection of smaller features that have a relatively high impact-on-abby/work ratio:
* A post it note feature that allows Abby to drop notes on her desktop, but also drag them to a panel edge where they stick on top (allowing notes to be irritating is key to standard use of notes as reminders).
* Show file attachments (but not little attachments like keys?) as first class objects. File attachments are usually more important to Abby than their containing messages
* Let Abby mark e-mail messages as tasks, and have due dates set on them. E-mail is the most common place for people to store todo items. Support this existing behavior better.
* OO.o help by example: given any OO.o object in the paste buffer let people "Recreate by example", which steps through how to create that item. Most people learn best by example, and it also allows people to build on "things they've seen". With traditional help systems you have to figure out what things are called, and hope that there's specific documentation on an item. This way Abby can use existing documents and things she's seen (people have pretty good "wasn't there something...." memories) to do new things in her own documents.
* Files and folders can be moved seemlessly between the panel and nautilus. The same items apply in both. In the distant future, allow snippets of text, images, and other document contents to be directly dragged in. Allows drag-and-drop to have the deferred property of cut and paste, but retains the nice physical aspect. Also allows for multiple items to be naturally in the "clipboard".
* Integrate music player seamlessly with the desktop. Use the desktop interface as the primary piece of the music player, not an "extra". In other words, the play list itself lives on the panel. Allow the music browser to be a floating window. Flips the dominance between the window presence and the panel presence.
* Mark relevant items as "sysadmin" in the .desktop files and provide a marker on the account that shows them or hides them. Cleans out the menus a lot for Abby. Also adds the possibility for Horatio to browse through a smaller admin-only tool set.
* Provide the ability to turn menu items from a non-base set "on", using a checklist. This is *not* full menu editing, but should easily fill Abby's demand for menu editing. More importantly, it reduces pressure for constantly increasing menu sizes over time. On the backend, Horatio can define two application sets: default applications, and applications which are "allowed" but not default.
* Collapse volume control to a single slider.
* Preferences cleanup, focused around Abby
* An improved calculator designed around quick, small "back of napkin" sort of calculations. Not modeled after the deficiencies of physical calculators. Abby will typically be working in another context, so a good calculator needs to be designed for running in small time windows, and make it very easy to get results into other apps.
On 2004-05-25T15:20-0400, Seth Nickell wrote: ) * Mark relevant items as "sysadmin" in the .desktop files and provide a ) marker on the account that shows them or hides them. Cleans out the ) menus a lot for Abby. Also adds the possibility for Horatio to browse ) through a smaller admin-only tool set.
If at all possible, I would like to steer away from the term "admin". In English, an administrator is a decision maker, director, executive, etc. It is a title of authority rather than a job description. (A telephone network administrator only gets his hands dirty working with POTS when cooking soup.)
I am not sure how we got to using the term "system administrator", but it may cause [be causing?] undesirable social change.
(Kinda like how calling creative works "intellectual property" is changing how people perceive creative works.)
If Horatio really is an administrator, he would not be dealing with maintaining an individual system, he would be directing someone else in that regard. Maybe "sysmaint"?
) * An improved calculator designed around quick, small "back of napkin" ) sort of calculations. Not modeled after the deficiencies of physical ) calculators. Abby will typically be working in another context, so a ) good calculator needs to be designed for running in small time windows, ) and make it very easy to get results into other apps.
The best calculator is probably quickly-gotten and easily-dismissed: Some hot key to pop up, type formula (input bar already has focus), hit Enter, hit Copy key (result is pre-selected), Escape to dismiss calculator entirely, hit paste key. No mouse, no looking at the screen, even.
The best calculator is probably quickly-gotten and easily-dismissed: Some hot key to pop up, type formula (input bar already has focus), hit Enter, hit Copy key (result is pre-selected), Escape to dismiss calculator entirely, hit paste key. No mouse, no looking at the screen, even.
That's a nice idea for power users, but no use for most, especially Abby. It must be easily discoverable, and easily laid out.
Seth's idea of the napkin-back calculator is great, maybe if it could hang off the panel and always be in front so that users could quickly use it, then dismiss it. If after clicking the 'Calculate' button the answer pane was highlighted and maybe copied, it would be fast to use.. is such behaviour inconsistent therefore bad for Abby's overall world?
I like the direction for the panel too.
Ed
On Tue, 2004-05-25 at 15:20 -0400, Seth Nickell wrote:
A collection of smaller features that have a relatively high impact-on-abby/work ratio:
[snip]
- Show file attachments (but not little attachments like keys?) as first
class objects. File attachments are usually more important to Abby than their containing messages
How would this look in the UI?
- Let Abby mark e-mail messages as tasks, and have due dates set on
them. E-mail is the most common place for people to store todo items. Support this existing behavior better.
Evolution has half of this feature already. If you rightclick on an email and select "Follow Up" you can enter a day (and time) by which the email needs to be followed up. But it doesn't appear then in the tasks view. Would it be better to: (i) perhaps change the UI to make it more obvious what this feature does (ii) extend the "follow up" feature so that the emails do appear in the tasks view (probably by writing a new evolution-data-server backend that talks to the email store) (iii) have a way of creating a new task from an email that refers back to the email? (the easy, hackish approach)
[snip]
On Tue, 2004-05-25 at 17:22, David Malcolm wrote:
Evolution has half of this feature already. If you rightclick on an email and select "Follow Up" you can enter a day (and time) by which the email needs to be followed up. But it doesn't appear then in the tasks view. Would it be better to: (i) perhaps change the UI to make it more obvious what this feature does (ii) extend the "follow up" feature so that the emails do appear in the tasks view (probably by writing a new evolution-data-server backend that talks to the email store) (iii) have a way of creating a new task from an email that refers back to the email? (the easy, hackish approach)
See: http://bugzilla.ximian.com/show_bug.cgi?id=45458
Havoc
- Let Abby mark e-mail messages as tasks, and have due dates set on
them. E-mail is the most common place for people to store todo items. Support this existing behavior better.
Evolution has half of this feature already. If you rightclick on an email and select "Follow Up" you can enter a day (and time) by which the email needs to be followed up.
Its very important not to require a due date, and to make marking as a task very simple (I suspect we should just replace "important" with "task", or perhaps just put all important messages in the task list). Most tasks don't have due dates, per se, they are just reminders.
-Seth
On Wed, 2004-05-26 at 11:14, Seth Nickell wrote:
Its very important not to require a due date, and to make marking as a task very simple (I suspect we should just replace "important" with "task", or perhaps just put all important messages in the task list). Most tasks don't have due dates, per se, they are just reminders.
The thing that makes this suck most (to me, a representative nontechnical user - ha) in Evo today is that the calendar/todo is modal with email. The todo list and calendar should be in some way ever-present, and when getting a todo item or event via mail I should be able to add it without closing the mail.
The little calendar drop-down on the clock might be much more useful if it were "events and todo items for today" for example, and when marking an email as a todo it could sort of fly up to that list or something. When an event is coming up the clock could sort of throb and make a chime noise or something. I don't know. Maybe it should be a dedicated gizmo and not a clock. Anyway, you get the general idea, calendar/todo are pesky as a separate app, they are more like a structure for your day that should be always available whatever you are working on.
Havoc
desktop@lists.fedoraproject.org
-
Aaron Bennett -
Daniel Reed -
David Malcolm -
Ed Mack -
Havoc Pennington -
John Dennis -
Seth Nickell