GNOME.org
 

Re: [Evolution-hackers] New Menu Layout

On Fri, 2005-04-29 at 15:50 -0400, Rodney Dawes wrote: 
On Fri, 2005-04-29 at 18:51 +0530, Not Zed wrote:
> 
> 
> Hmm, this seems to be a pretty big patch.  It would probably be easier
> if you just stuck to the ui parts in the patch, and not a major
> re-factor of bits of code (admitedly needed refactoring).
> 
> Which parts were crashing?

Calling em_folder_selector_get_selected_path () before making a call
to em_folder_selector_get_selected_uri () on the same widget, seems to
cause memory corruption, and a subsequent crash.
should've got jeff to look at it.

> Issues:
> - Folder->Mark Messages As Read does nothing, i presume this was the
> old 'mark all messages as read' one, and it doesn't read the same
> anymore

Hrmm. I must have overlooked that. I thought it worked, given that we
already have something that does this. I'll look into that.
So what happened to the different forwarding message types?

And what happened to the 'hide read messages' and related stuff?

These are pretty major functional changes, not just a re-arranging of menus.

> - folder->subscriptions makes no sense, it isn't a folder operation.
> if everything else that was in tools is now in edit, why not move it
> there?

Everything else that was in tools, for the most part, seem to all be
things that should be in preferences anyway. This is why they were moved
to Edit, next to the Preferences item.
Subscriptions are a preference too, by that logic.

> - message->mark as ... doesn't make sense much either.  1. it is hard
> ot get to, and 2. they alter the message state, i.e. edit it, they
> don't alter the messages themselves, which are immutable.

They don't alter the messages themselves. They alter metadata related to
the messages. They are directly related to the message, and we think
this will make them easier to find. Nobody ever knew that these items
even existed in the Edit menu before. They were not discoverable. If the
Message menu is not the place for them, then user testing we do on them,
should show us that, and we can change it.
It is still very hard to get to, and one of the most commonly used functions in a mailer.

The whole message menu's layout is strange, the groupings and order are strange.

> - similalry message->goto doesn't make much sense, since you're
> altering the view.  These two ops are pretty likely some of the most
> often accessed ones, it seems odd to change them, they were quite fine
> where they were I thought.

You're going to a different message. You aren't altering the overall
view of the application. You're just loading a different page or
document. And if this proves ineffecient, we can move them. This is why
we are doing user testing on these changes, once they get into CVS.
It's still changing the view state, not the message.  Certainly as much as changing 'threaded' mode changes the view.  Maybe 'threaded' should be in folder?  And 'hide deleted messages' as well?  And most of the rest of the view folder must live in message, by this logic?

Shouldn't you have done this testing before affecting every user of the application?  It seems a little strange to do this, and then if changes are required, go and mess up everyone who is testing the 2.3 codebase.

> - a bunch of plugins mess up the menu, there is now a blank menu past
> help for a few items that used to be in actions (save attachments and
> mailing list actions plugins).

The Mailing List actions show up under the Message menu for me. Are you
sure all of the patch is applied/installed properly for you?
It applied cleanly, and i did a make && make install.  Unless the patch is out of date. Maybe it didn't build properly.

> - the actions menu in the other components now shows up after help
> (maybe this only happens if you start in the mailer).

This is a slightly annoying side effect that will be remedied as soon as
possible. The problem is that everything is a single app, so the base
menu structure all comes from the same place, so changing the menus in
one component is very difficult to do, without possibly slightly
affecting other components. There were similar issues during the 2.2
cycle, with the plug-in menus breaking the menu structure, even just in
the mailer. We want to get the mailer stuff in as soon as possible
though, so that it can get testing, while we also work on getting the
other components migrated to the new structure.

> - its a vfolder not a search folder

VFolder is a horribly confusing term for a user to see. It doesn't
describe at all what the folder does. It's a branding term that we need
to get rid of.
Can't you think of a better name than search folder then?  Its naff.

> - 'tools' seems to be a bit redundant, everything that was in it is
> now in tools, except for some arbitrary choices which aren't.

I presume the second "tools" here should be "edit". If we could just
hide the hole idea of switching components within evolution itself, and
just get rid of "Tools", the buttons, and the preference for their
appearance, I would be more than glad. The "Tools" menu is still around
for lack of a better place to shove the components.
What was wrong with "view"?

> - what happened to cut and paste?!?

Cut and Paste are editing actions. You can not cut text from, or paste
text into, a read-only document. "Move to Folder" does the same thing.
Select mails, hit C-S-v, and it moves the items to the folder.
Uh.  Yeah, like dnd does the same thing.  We could just force everyone to only use dnd then right?  Or remove dnd - wouldn't want to confuse users with a choice, and dnd needs that nasty mouse thing.

There is quite a lot of code to support cut and paste of messages, is that just going to hang around?

> - folder->expunge seems to be in a weird spot.  there are other menu
> items which appear to be in strange locations (add sender to
> addressbook, 'go to', mark as, 

Weird how? It's an action on the folder. It seems like it belongs in the
Folder menu. Although, I would much prefer to get rid of "Expunge" all
together, and just have "Empty Trash". I think a lot of users get
confused by the term "Expunge".


It is directly beneath the non-functioning and confusingly named "mark messages as read".

That seems to be a weird spot to me.

"subscriptions", if it must live in that menu, is similarly in an odd spot, at the top, near "new".  Rather than at the bottom, under "properties".

> - edit select all text/deselect all text aren't hooked up.  what does
> deselect all text do, sounds uncommon.

We can probably drop Deselect all. It is mentioned in the HIG. If it
were hooked up, it would clear the selection of text made in the message
display. I must have overlooked these. Will try to get them hooked up
as soon as I can.
What an odd thing to have in a mailer.  Deselect all text?  Who ever does that in a mailer?  The hig does seem to have some problems with real applications ... I've never heard or noticed such an option in 20 years of using computers.

> Anyway, take most of those comments with a grain of salt (like i'm
> sure you will), although i find no paste a bit of a killer (this is
> how i normally move mails around for example, and i'm sure i'm not
> alone).  Tools looks like it has to die though.

Yeah. I am not sure what to do with Tools though. As I said, it's there
because there is no better place to put the component menu items. If we

view.  You're changing the whole view of the application aren't you?  how can it not belong in view?

can fix up Evolution in the 2.3 cycle to hide the other component
things, and just drop the internal switching stuff, that would be
awesome. I'm not sure if we can do that though.
Why would that be awsome? 
As for paste, I think actually using Move/Copy to Folder would be much
faster from the keyboard, and in general, as you don't have to switch
folders, so there is a lot less work you have to do as a user. Also,
they were confusing at best, especially given that they were context
sensitive items.
Not really, it pops up an annoying window that you have to navigate to with the mouse anyway (if you have focus follows mouse).

ctrl-c and ctrl-v are easily remembered shortcuts in an easy to reach place.

shift-ctrl-y is neither.

But, the sooner we can get this in, the sooner we can get proper user
testing on it, and the sooner the rest of the components can get fixed
as well. And, there will be user testing.

I'm sure microsoft don't wait till a public beta release is patched with radical changes before doing their user testing.  Shouldn't you have been doing this user testing in the last 3 months while were in ui freeze?  It isn't hard to build a patched package for installing on a user testing lab.  Surely.


The patch at least has to work anyway, so awaiting another one.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]