activity configuration UI

[Thomas Pfeiffer]

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