Re: Feature requests

Great idea Thom!

An iTunes style list with "smartLists"...  I hadn't ever thought of 
that...  We may come up with a few different styles of Buddy Window to 
accommodate different user requirements....  But that will have to wait 
until a future release.

Alan
------
Alan Humpherys
Fire Development Team
http://fire.sf.net

On Jun 25, 2004, at 1:02 PM, Thomas Peters II wrote:

> On Jun 25, 2004, at 5:25 AM, Sixer wrote:
>
>> I'm not sure if this is the place this should go, I apologize if not.
>>
>> 1) I'd like to be able to disable the status column. I use colors to
>> determine what status users are in so the status column is a bit
>> overkill to me.
> [snip]
>> 5) Ever thought of implementing alternating row colors in the
>> buddy list?
>>
>> You guys are doing a wonderful job.
>
> Kind of makes me think of the iTunes interface. It has a contextual 
> menu for the columns that allows for showing or hiding each column. 
> Very convenient and easier to show/hide a single column than a 
> checkbox in a dialog. The Auto Size Column and Auto Size All Columns 
> options would be nice, too, which I sorely miss. There's nothing like 
> automatic narrowing to get the window contents smaller to make Zooming 
> more effective.
>
> Hmm, but what if it went further? What if the Groups were listed like 
> playlists instead of with disclosure triangles? There'd be something 
> like a Library playlist for listing every buddy (perhaps named All 
> Buddies) and separate service group lists for locating buddies by 
> service for each account. And Online and Offline groups for quick 
> reference. Perhaps each group could be optional. Other groups would be 
> user defined and rearrangeable (as they are now), unlike in iTunes 
> where the user defined playlists are automatically alphabetized.
>
> The equivalent area where songs are in iTunes would contain a list of 
> Buddies with the alternating row color for easier reading. The columns 
> would be service, buddy name, and status. The Service and Buddy column 
> wouldn't be rearrangeable, similar in practice to how the number and 
> song columns in iTunes can't be moved. The Buddy column would remain 
> visible at all times and the other two can be shown/hidden with the 
> contextual menu. With the service and buddy columns locked down, 
> there'd be nowhere to move the status column unless there were other 
> columns, so none of the columns would be rearrangeable. But that seems 
> a bit extreme, so maybe instead have all columns rearrangeable and 
> require only the Buddy column to remain visible.
>
> Naturally, there'd be an idea for separate Name (or ID) and Alias 
> columns for the buddy names, perhaps with the Alias column contents 
> editable. Then the user can decide to have ID or Alias or both by 
> using the contextual menu, and whichever order by rearranging. Though, 
> with multiple columns for buddy identification, perhaps only require 
> at least one column remain visible (doesn't have to be a name column), 
> i.e. the last visible column couldn't be unselected so the window 
> wouldn't be empty and mysterious.
>
> Other information could be associated with each buddy and easily 
> viewed in new columns. For instance, how about a Relation property? 
> Kind of like Genre, with Family/Friend/Classmate/Church or whatever 
> the user defined. This could be useful for smart groups or sorting 
> columns, such as a smart group of all buddies whose Relation contain 
> Family, or maybe Friend and Jujitsu. A user would simply type more 
> than one in the Relation field and it would be simply a contained 
> match. Another property might be Location, intended to contain 
> something like Country and province/state, but could have anything. 
> There's no requirements of exactly what a user puts in the field, but 
> it's there for easy grouping and organizing when sorting columns or 
> using smart groups.
>
> Examples of usefulness: maybe you want to arrange to meet everyone you 
> know in town at a local theatre or park, or maybe you want to chat 
> with everyone in your club/class. Being able to sort/group buddies in 
> this way (location, interest, etc.) would simplify knowing who is 
> online and therefore who to invite to a group chat. No need to limit a 
> buddy to a single group or view multiple instances of the same buddy 
> in multiple groups.
>
> Of course, one of the options of a smart group would be by Status 
> Type, so one of the criteria could be 'Status Type is not offline', 
> which means the group would automatically update as matching buddies 
> sign on/off. This associates the option for viewing online/offline 
> buddies with a custom group instead of all groups all of the time. 
> Just a small example of how smart groups can also become custom views, 
> hence customized usefulness per task, without having to switch options 
> all of the time.
>
> Extra buddy info for organizing wouldn't need to rely on each service 
> to be able to store such info because in this case Fire is providing 
> the ability to organize data. Giving the extra properties non-specific 
> names (e.g. Location) makes the stored info rather innocuous and 
> harmless, and allows the user to decide on what details and how it 
> would be most useful for grouping.
>
> Ideally, it'd go a step further than the iTunes, iPhoto, etc 
> interfaces by allowing the Groups list area to be hidden, which would 
> allow for the Buddies window to be nice and narrow. Hmm, a drawer for 
> the Groups list might be okay and could be toggled from the toolbar or 
> Cmd-Shift-G shortcut (and renaming "New Group Chat" to Cmd-Shift-N, 
> variation of "New Chat" shortcut for consistency). Or maybe if the 
> vertical resize bar for the groups list was in the style of the 
> Finder's sidebar in which a double click on the resize bar opens or 
> closes the group list area, and then that'd only be a negligible few 
> extra pixels in width. And the shortcut could still be used, too. 
> Though, a click on the Zoom button afterwards may be necessary for the 
> window to be more readable or more narrow, depending on the window 
> size.
>
> This similarity with other apps would make doing certain tasks more 
> familiar and hence intuitive, such as customizing a list of buddies 
> and info (service, name, alias, status, relation, etc.), or creating 
> and managing groups, or locating buddies to IM, or organizing buddies 
> (associating interests, location, and info).
>
> Hmm, probably sounds like a major change, but it's mostly just the 
> Buddy window and that would look the same when the group listing is 
> collapsed. The extra buddy properties are actually more of a bonus for 
> organizing and remains behind the scenes unless the user wants to view 
> the columns.
>
> Something like this would still allow for a small Buddy window. 
> Imagine: you could have just the Alias column showing, auto size the 
> column for the perfect width, Zoom the window, and then it'd be 
> smaller than the current Buddy window because it wouldn't have a 
> disclosure triangle and the drawer would be closed. Even using a 
> vertical resize bar for accessing the groups wouldn't take more space 
> than the disclosure triangle, but that's not the point. That point is 
> really about nobody having to worry about the Buddy window becoming 
> bigger than it is now.
>
> An IM to a buddy could easily be opened using the keyboard even if the 
> buddy isn't visible in the Buddy window. Simply use the keyboard 
> shortcut to reveal the groups (if necessary) which moves the selection 
> to the groups, use the arrow keys to select the group, tab into the 
> buddies list, arrow down to the buddy and hit return. Using the mouse 
> would also be easier than now because a whole line of text can be 
> clicked to open a group instead of just a disclosure triangle.
>
> The disclosure triangles have been a nice interface, but they're not 
> vital. Currently, the groups in the buddy list can seem too separating 
> for merely listing who's online. There are certain circumstances where 
> groups are useful to see when viewing who's online, such as noting 
> which members of a club are online. In that case, I'd be fine viewing 
> just that group and no others, or a larger list sorted by group. 
> However, the size and location of the disclosure triangle makes 
> showing/hiding the groups feel like a challenge of mouse pointer 
> accuracy when I'm in a hurry, and having them all open feels 
> overwhelming when I just want one group open to find someone.
>
> In addition to sorting by clicking on column title, there could be an 
> optional toolbar pop-up item for sorting by a particular column so the 
> sorted column wouldn't have to be visible. A horizontal dividing line 
> (black and a couple pixels thick) could help indicate the similarities 
> in the sort. For example, after sorting by service the thin divider 
> lines would visually delineate the sort without the need to have the 
> service column visible for reading, and the sections would be 
> recognizable by content.
>
> And of course, an optional search box in the toolbar could make it 
> easy to quickly find all buddies matching text in all buddy properties 
> such as ID, Alias, Relation, Location, etc. As in iTunes, it can 
> become a sub-search for a smart group: the smart group is the main 
> search criteria, and then the toolbar search box allows for quick 
> sub-searches.
>
> Admittedly, all of these ideas are just variations of what's available 
> in other apps, but that helps make such an interface familiar and easy 
> to use. Keeping the interface tight and clean (similar to the way it 
> is now) combined with added flexibility and control over grouping and 
> sorting buddies allows for ease of use per task and lets everybody 
> powerfully customize their views for their needs.
>
> So with the extra info associated with buddies, it's no longer just 
> each buddy in a single group, or having the same buddy (duplicates) in 
> multiple groups and sometimes seeing all the duplicates. Instead, this 
> focuses on custom groups of buddies based on association of single or 
> multiple criteria. Sort of like circles or cliques of friends, and how 
> they overlap each other like unions of sets, but perhaps in ways we 
> didn't realize before, which might suggest and encourage new cliques 
> to form which creates a tighter bond amongst the whole. And of course, 
> this leads to more communication through IM.
>
> Being able to have multiple custom views (through the use of smart 
> groups) allows for the Buddy window to be set up by task. Different 
> possible lists include: list of buddies in a club; list of buddies in 
> town; list of buddies in a project; perhaps another club, timezone, or 
> project; list of family members; list of family members in town. 
> Associated tasks could be: chatting about the upcoming tournament; 
> chatting about getting together for LAN game; chatting about a family 
> get-together; chatting about a carpooling to a local volunteer event. 
> Each task can be aided by having a simplified, custom view of the 
> potential people to invite into a group chat. Such a view can help 
> with making a decision of when to chat to who.
>
> The Buddy window becomes almost infinitely useful for any chatting 
> task without becoming overwhelming because everything else is hidden 
> out of the way by user choice. And with settings stored with the 
> group, everything is changed with a single click on the group or smart 
> group instead of the several clicks that may be required in 
> preferences and the toolbar and such.
>
> Well, hmm, just an idea or two...
>
>
> --  Thom



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Fire-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fire-talk
Have a question? Please read the Fire Frequently Asked Questions:
http://fire.sourceforge.net/faq.shtml