On 28.03.2012 14:11, Fania Bremmer wrote:
* change title to "Activity Settings" ("settings" being less "tech" than
"configuration" and shorter, at least in english; use title capitalization)
+1. I would even prefer a title that integrates a verb, like "edit activity".
But that's a wording question. I guess we use more often nouns than verbs... if
we decide for one, we should apply it everywhere.
"Edit Activity" might work, yes. And I'm generally strongly in favor of verbs,
because most of the time a dialog is used for a task.
* change "Activity name:" to just "Name:". that it is an Activity is implied,
and is redundant with the title directly above it. the name also appears right
next to the buttons on the activity view so there is an evident corelation
+1. Maybe even write the label into the text field until the user enters the
first key? So we would save even more space.
+1 for putting it into the field, consistent with "Search"
* move "Lock as private" next to the Name entry. this eliminates an entire row
from the vertical space usage and puts all of the controls in one place
We moved it from up there to the very bottom, because it implicates a second
page with the setting of the password. To link this clearly in the user
interaction flow, we decided to put it directly on top of the buttons, to show
with the changing button label that one more step needs to be done, to have a
final private activity.
I'd still vote for entering the password directly on switch (instant apply).
Another plus: If the user cancels the password entering dialog, the switch can
just be moved back to "off", so the user sees that the activity is still not
private. Currently if the user cancels, the dialog is closed so the user does
not directly get the feedback that this particular change has been reverted.
* change "Lock as private" to just "Private". the phrase "Lock as private" is
a bit awkward (it is not a natural phrasing one would use in conversation) and
specifying "Lock" speaks to the mechanism rather than the intention of the
user. the intention is "this is private"; the mechanism we use is "locking
it".
Before integrating this phrase we tested with a lot of people. We tested
different words and phrases like "protect, lock, mark...as private, secure" etc.
The result has beenthat most people preferred and understood the phrase "lock as
private". Here both results, the locking of the activity with a password AND the
encryption of the private data, have been understood.
Only "Private" would not clearly communicate the underlying action for the user.
I don't really like "Lock as private", but if that's the one that fared best
with the users, I think we should still keep it. Don't know what it looks like
if it's placed next to the name, though. Might make the row a bit too long.
one further thing i'd like to experiment with is moving the save/close buttons
into the title bar. some other mobile OSes do this and it would accomplish two
things: better use of screen real estate, make it more obvious to people where
these buttons are. people often do not find the buttons at the bottom; i've
watched dozens of people go through the UI and this is a recurring issue.
+1, also because the buttons are often covered by the virtual keyboard. But if
we move buttons up in the title bar, we should check that we make this is a
general UI guidelines and have it consistently in the system
I won't give up yet on eliminating the buttons whenever possible. But if that's
not possible or wanted, I'm fine with moving them into the title bar. And of
course I'll write guideline for that.
on thing that would make this harder is that currently when marking an
activity as "private" the label on the Save button changes to a very long
text. i also question if this is really needed or not: mark it as private and
when "save" is pressed take the necessary steps for a private activity.
see above, we tried to make it clear to the user that without the
private-activation he can just save or create the activity. With the
private-activation he needs to fulfill one more step, which is the password
dialog.
This would be solved by opening the dialog directly when the user switches (see
above).
p.s. i don't have locking activities working here atm, so i can't see if there
is any UI for changing the password, or if the password is asked for every time
a private activity is saved ... in any case, i'm more concerned at the moment
about the default UI.o/active
One thing in general: I am thinking about a while now about some kind of wizard
in this case: we could split those 3 steps into a small, little wizard, at least
for the creation of new activities. That makes it easy to add different steps in
between, like the private activities step -> it would be a handy and guided flow
for the user, where he can quickly create a new activity. Maybe later we get
even more stuff, like tagging etc for activities, which would be convenient to
add in this wizard.
But I must admit that for editing an existing activity, a wizard would be
strange.
Well, yes, as I already said in my other email ;)
So, thumbs up for your goal to improve the dialog (both dialogs, as create new
activity and edit activity are the same).
+1
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
