Ricky,

I'm glad that you like the solution. Of course you're right that an IM 
option would be silly in an IM context, and that Teleport would be 
equally silly when the person is offline. This was just a quick XML 
mock-up to show you what it would generally look like. A complete 
implementation would include controller logic to either hide or grey-out 
options that are invalid whenever the drop-down is opened.

-Melinda

Ricky wrote:
> This looks like a pretty valid solution.  As to which is the default 
> when... I don't know.  I do know that the teleport option should not 
> be available for offline users, not just not the default.
>
> Also, if you are in the IM window... Why would there me an IM option?
>
> Ricky
> Cron Stardust
>
> On Thu, Jan 21, 2010 at 5:31 PM, Melinda Green 
> <meli...@superliminal.com <mailto:meli...@superliminal.com>> wrote:
>
>     I have a suggestion for a solution that gives the best of both
>     worlds by not adding extra controls, keeps the most common action
>     one click away, and still lets you get at the other
>     person-to-person actions with the least extra effort. The solution
>     is to use a "flyout" button instead of regular buttons. The viewer
>     currently uses one for the "Communicate" toolbar button and
>     another for the "Save" button in the snapshot tool when set to
>     save to disk. Take the snapshot case: It looks just like a "Save"
>     button and works as you would expect, but there is an additional
>     "Save As" option under the drop-down triangle control.
>
>     I've mocked up the XML to show what it would look like in an IM
>     tab. See the attached a screen shot. Here's the XML for reference:
>
>      <flyout_button bottom="-40" follows="left|top" height="20"
>     label="Teleport" left="5"
>          list_position="below" mouse_opaque="true" name="tp_btn"
>     tool_tip="Offer teleport"
>          width="85">
>       <flyout_button_item value="profile"
>     name="profile_item">Profile</flyout_button_item>
>       <flyout_button_item value="teleport"
>     name="tp_item">Teleport</flyout_button_item>
>       <flyout_button_item value="im"
>     name="im_item">IM</flyout_button_item>
>       <flyout_button_item value="call"
>     name="call_item">Call</flyout_button_item>
>       <flyout_button_item value="pay"
>     name="pay_item">Pay</flyout_button_item>
>      </flyout_button>            
>     Neat, eh? Using this approach we can use whichever default
>     operation makes the most sense in each situation, with the rest of
>     the operations in the drop-down. If desired, we can probably even
>     code it to automatically switch defaults depending upon friend
>     online status, etc. Users who do not know about or discover the
>     added functionality will be no worse off then they would be with
>     the button schemes being considered here, and once they learn
>     about the additional options, they will come to expect the same
>     pattern in other P2P situations. The only thing that remains to be
>     decided is the default behavior in each situation. We can continue
>     to debate that here but this appears to solve the main problem of
>     having either too many controls or not enough.
>
>     -Melinda
>
>
>     Ardy Lay wrote:
>
>         Haha...  I see.  So roll-back it is.  I like the idea but do
>         admit the implementation of a button that
>         changes labels can be confusing. I am often torn between
>         always having the button I want handy
>         and keeping the UI simple by not duplicating anything.  In
>         most cases I just use what I find.
>
>         (Takes notes for future reference.)
>
>         Philippe (Merov) Bossut wrote:
>          
>
>             Hi,
>
>             OK, got it. After all folks, that's your project so, if
>             everyone hates the feature (or at least, there's enough
>             outcry that there's little incentive to change the
>             previous behavior), lets roll it back.
>
>             Sorry Yann...
>
>             Cheers,
>             - Merov
>
>
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/SLDev
>     Please read the policies before posting to keep unmoderated
>     posting privileges
>
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to