[Sugar-devel] buddy tags

[Gary C Martin]

On 4 Aug 2009, at 04:54, Eben Eliason wrote:

> On Mon, Aug 3, 2009 at 10:16 PM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>> Hi Eben,
>>
>> On 4 Aug 2009, at 02:19, Eben Eliason wrote:
>>
>>> On Mon, Aug 3, 2009 at 3:39 PM, Gary C  
>>> Martin<gary at garycmartin.com> wrote:
>>>>
>>>> On 2 Aug 2009, at 15:00, Tomeu Vizoso wrote:
>>>>
>>>>> Hi Gary (and others),
>>>>>
>>>>> what was decided about buddy tagging?
>>>>
>>>> No one else has commented yet :-(
>>>
>>> I had a brief conversation with Christian about this recently. He  
>>> said
>>> he'd try to catch up on the thread and maybe give a few comments.
>>
>> Fab, that would be great!
>>
>>>>> Were you interested in working on it?
>>>>
>>>> Yes, I've just added some new mock-ups (keeping them as simple/ 
>>>> achievable
>>>> as
>>>> possible), so maybe someone else can take a look at them and  
>>>> provide some
>>>> feedback:
>>>>
>>>>       http://wiki.sugarlabs.org/go/Design_Team/Proposals/Buddy_Tags
>>>
>>> I think the settings panel looks like a good start. I wonder if we
>>> should stick with "tags" here, or if it would be worth calling  
>>> this a
>>> "description" or "things I like" or something similar.
>>
>> Yea, I was playing safe with the input box name. I wanted to avoid
>> suggesting folks type in a natural language sentence or paragraph.  
>> If we had
>> tokenised text field support, life here would be easier (and else  
>> where we
>> want folks to use tags) ;-)
>>
>>  http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface#Tokenized_Text_Fields
>>
>>> The palette, on the other hand, doesn't work as you've mocked it up.
>>> The primary palette is a fixed height, and only supports single line
>>> primary and secondary titles. I think the tags/description belong in
>>> the secondary palette instead. See
>>> [http://wiki.sugarlabs.org/go/Design_Team/Designs/Activity_Management#03 
>>> ]
>>> for a related sketch. We've abandoned the gray background, and we
>>> don't have avatars or structured content as shown here, but I  
>>> think we
>>> could add a "section" to the secondary palette containing this extra
>>> info. It would expand, but the primary palette would always be a  
>>> fixed
>>> size.
>>
>> Thanks. I didn't know that. I will amend my mock-ups, should work  
>> just as
>> well with that change.
>>
>>> It might also be nice to have the ability to have a button in one's
>>> own palette that links directly to the "about me" section of  
>>> settings
>>> to change the info. This will also improve discoverability. The
>>> ability to open the settings to a specific section (and even  
>>> anchored
>>> subsection, perhaps) is something we've wanted to expose in many
>>> places. It might be a nice task for someone looking for a nice
>>> self-contained feature to build.
>>
>> On the fence about this one, I find one's own palette is getting a  
>> little to
>> long already (My Settings, Logout, Restart, Shutdown, Register).
>
> Ugh! "Register" really needs to be dealt with; the fact that it ever
> entered this menu is frustrating, and it is another long-standing
> temporary hack that never got fixed. The intended solution for this
> particluar feature is to represent school servers in the neighborhood;
> The "Register" action is supposed to be performed on the server, not
> on "you".

+1 that would be great.

> Isn't "My settings" just "About me" in disguise? Maybe we should just
> change that string. There's no need to have the same button appear
> twice in the palette

So just a string change, you'd still end up at the top level of the  
control panel, right?

> I suppose there's no ridding of 'Logout",
> "Restart", and "Shutdown". =)
>
>> Hmmm, random thought. Should clicking on your buddy icon open "My  
>> Settings"
>> as the default operation? Right now it's just a pretty picture with a
>> palette hanging off it. That way you'd just click your buddy icon  
>> and pick
>> "About Me", avoiding all those nasty techie strings.
>
> That's an interesting idea, though if the button is in the palette,
> that might be enough. I might instead suggest as a global rule that
> clicking on a buddy should reveal the (full) palette by default.

Might that conflate left click vs. right click behaviour? But, other  
than that, yes this is a fair call I think, and resolves the issue  
(safely) of what would be the default action when clicking on some  
other buddy icon. Perhaps the general rule "clicking icons with no  
default action should reveal full palette" can be used else where  
(e.g. battery device frame icon, network device frame icon).

Regards,
--Gary