Re: [JDEV] Jabber Client Design Tutorial
I just posted some ideas about a humane interface at: http://interface.blogspot.com This is the first draft and there's a lot (of explanations) missing but I thought you might wanna look at it anyway. If I get time I'll make some pretty screenshots just like Michael:-) Rikard _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Fri, Sep 28, 2001 at 10:44:15AM -0600, Dave Waite wrote: I'll take a stab; how about: [stab] How is that? :-) Really good :-) dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
I have several here: http://www.saint-andre.com/jabber/xml/ Peter -- Peter Saint-Andre email/jabber: [EMAIL PROTECTED] web: http://www.saint-andre.com/ On Fri, 28 Sep 2001, Stuart Dortenzio wrote: Can someone please help! I sent a request to the admin group for a working sample of a jabber.xml server file and got no response. We are trying to setup a jabber server for conferencing and can't get it to work. Does anyone have a copy of a working jabber.xml config file such as the one used on the jabber.org server? Thanks, Stuart Message History From: Dave Waite [EMAIL PROTECTED]@jabber.org on 09/28/2001 10:44 AM CST Please respond to [EMAIL PROTECTED] DELEGATED - Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: [JDEV] Jabber Client Design Tutorial Michael Brown wrote: Perhaps as a first step we can find some agreement about terminology (roster vs. contact list vs. buddy list, transport vs. gateway, etc.) I actually prefer Contact List but Roster seems to be well defined for Jabber - which I can live with - although it does sound a little like there should be some house-hold chores involved :-) Contact list is my favorite. All three imply that only Instant Messaging users are in the List. I've always been confused between Transports/Gateways/Agents so if someone could clear that up for me that would be great. I'll take a stab; how about: Entity - Any thing which interacts with the Jabber system, and/or which is available to be interacted with by other Entities in the Jabber system. Jabber IM User - An entity using the Jabber system as an Instant-messaging platform. Component - An entity which has a trusted relationship with a Jabber server, and which provides some set of services to Entities (either to Jabber IM Users or to other Components) Gateway - A component which provides direct access to non-Jabber services to Jabber IM Users. No distinction is made to whether the component also allows a mapping from the non-Jabber service to access all of Jabber Agent - A component which provides a mapping between a non-Jabber services and the Jabber system by authenticating with that remote system on behalf of a Jabber User. Transport - An agent which specifically provides access to a non-Jabber Instant Messaging system. Examples: * Jabber conferencing would be a component, because it is providing a native Jabber service * IRC access would be considered a gateway since IRC is a remote service, but there is no registration required * Access to an IMAP mailbox (some sort of jabber-biff) would be considered an agent, since registration is required * Access to AIM or Yahoo! would be considered a transport How is that? :-) -David Waite ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Peter Saint-Andre wrote: Perhaps we can add this stuff to the recently-rediscovered glossary? http://docs.jabber.org/general/html/glossary.html yep, that sounds good. i'm all for a new, improved Glossary. also, stpeter, i'd like to work with you on re-doing the jabber user's guide. make it more 'client-independant' got some ideas. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
There is so much talk on what a Jabber Client should be, me thinks we should build a summary of the arguments for future UI reference. And use that to direct new UI IM clients as they get started on their journey to swell design. Any new UI documents in the works as a response to the first one (which honestly i enjoyed reading as an albeit contested guide) ? I would be happy to aggregate the existing public discussions, but I think are lots of offline talks going on as well. -john Ahh - it all becomes clear. That makes the WinJab a bit less perplexing to me. Doesn't suit me at all (but for those who like it that's great). I'm all for a separate email client - applications should be seperated where possible - it's the OS's job to tie them together. A combined email/IM client means that 50% of it is bloat for anyone who already has an email or IM client that they are happy with. Winjab isn't a IM and an email client... it doesn't do POP, IMAP or SMTP :) But what I meant was that at some point, I could see offline IM msgs being used just like email. Hence, the GUI design similar to an email client. Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Perhaps as a first step we can find some agreement about terminology (roster vs. contact list vs. buddy list, transport vs. gateway, etc.) Peter -- Peter Saint-Andre email/jabber: [EMAIL PROTECTED] web: http://www.saint-andre.com/ On Thu, 27 Sep 2001 [EMAIL PROTECTED] wrote: There is so much talk on what a Jabber Client should be, me thinks we should build a summary of the arguments for future UI reference. And use that to direct new UI IM clients as they get started on their journey to swell design. Any new UI documents in the works as a response to the first one (which honestly i enjoyed reading as an albeit contested guide) ? I would be happy to aggregate the existing public discussions, but I think are lots of offline talks going on as well. -john Ahh - it all becomes clear. That makes the WinJab a bit less perplexing to me. Doesn't suit me at all (but for those who like it that's great). I'm all for a separate email client - applications should be seperated where possible - it's the OS's job to tie them together. A combined email/IM client means that 50% of it is bloat for anyone who already has an email or IM client that they are happy with. Winjab isn't a IM and an email client... it doesn't do POP, IMAP or SMTP :) But what I meant was that at some point, I could see offline IM msgs being used just like email. Hence, the GUI design similar to an email client. Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
There's one thing I agree with. :) I do feel we should come up with a nice little guide to the suggested terms to use for various features, when/where they should be used, and how they can be explained to the user. Now if only I could find a way to sleep *and* do this stuff at the same time... Julian Peter Saint-Andre wrote: Perhaps as a first step we can find some agreement about terminology (roster vs. contact list vs. buddy list, transport vs. gateway, etc.) Peter -- Peter Saint-Andre email/jabber: [EMAIL PROTECTED] web: http://www.saint-andre.com/ On Thu, 27 Sep 2001 [EMAIL PROTECTED] wrote: There is so much talk on what a Jabber Client should be, me thinks we should build a summary of the arguments for future UI reference. And use that to direct new UI IM clients as they get started on their journey to swell design. Any new UI documents in the works as a response to the first one (which honestly i enjoyed reading as an albeit contested guide) ? I would be happy to aggregate the existing public discussions, but I think are lots of offline talks going on as well. -john Ahh - it all becomes clear. That makes the WinJab a bit less perplexing to me. Doesn't suit me at all (but for those who like it that's great). I'm all for a separate email client - applications should be seperated where possible - it's the OS's job to tie them together. A combined email/IM client means that 50% of it is bloat for anyone who already has an email or IM client that they are happy with. Winjab isn't a IM and an email client... it doesn't do POP, IMAP or SMTP :) But what I meant was that at some point, I could see offline IM msgs being used just like email. Hence, the GUI design similar to an email client. Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Perhaps as a first step we can find some agreement about terminology (roster vs. contact list vs. buddy list, transport vs. gateway, etc.) I actually prefer Contact List but Roster seems to be well defined for Jabber - which I can live with - although it does sound a little like there should be some house-hold chores involved :-) I've always been confused between Transports/Gateways/Agents so if someone could clear that up for me that would be great. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
I've always been confused between Transports/Gateways/Agents so if someone could clear that up for me that would be great. First of all a warning. I am gong to provide canonical deffinitions then I will provide usage deffinitions. Some of what I say will seem incorrect to some people, that's ok. These are the terms as I understand them, Where you feel I am wrong, we differ in opinion. I am willing to listen to your arguments, just don't make them too convoluted, I prefer simple ideas. Transport is a layer that is part of the standard communication protocol for an application. For example TCP is a transport layer of the TCP/IP protocol stack. Other transport layers include UDP and in some books ICMP. Other transport layers have been built on top of IP, but TCP is the most widely known. In Jabber the Transport is XML. It is the protocol that Jabber uses for all forms of communications. In TCP/IP, a gateway is an application layer translation point. For example if you are using a FidoNet e-mail account and you wish to send mail to my SMTP/POP3/IMAP account, your e-mail has to go through a gateway. A proxy or may be considered a gateway, though generally it is not doing protocol conversions. In Jabber the equivalent is the Transports to communicate with Yahoo, MSN, AIM, ICQ, IRC, etc. By this definition the Conference Transport would be a gateway that provides a jabber client to multi-point jabber client translation. A agent is not something that has an equivalent TCP varient, because it really is more of an application than a protocol. My personal feeling is that an agent is something that performs actions so you do not have to. Examples are Archie, Veronica, Google, WebCrawlers, various PIM's, chatbots, and the like. JunkBusters is a proxy that I think falls closer to being an agent than a gateway. I would consider the chatbots in various conference rooms to be agents either as journaling programs to keep track of what happened, Within Jabber itself, the JUD, and JSM processes appear to me to be agents. There are very wide variations in the application of these terms. For example, Windows calls your default route a Gateway. Jabber uses Transports as a term for what I personally consider Gateways. I don't plan on going back into time and telling microsoft No you can not use 'Gateway' for that field. Gateway has a very specific meaning that has nothing to do with your usage Likewise for Transports in Jabber. The term is in wide use and it is less confusing at this stage to explain to people that 'this module provides a transport mechanism for some other feature' than it is to go through all of the documentation and correct it. GNU/Linux is the correct term, but I will continue to call it Linux, because it means less bagage to carry arround when trying to explain things to people. Also it is faster to say Linux than GNU/Linux and is easily twice as fast to type. -Rusty ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
The main problem was that I needed a three-phase icon (for when you get an event from someone in a collapsed group), and couldn't think of anything beyond the + and -. Also, to replicate the +/- style usually means showing the tree branches, which takes up horizontal room, resulting in wasted pixels. You can indicate activity within a collapsed group by blinking the group title or something like that. And I think that using the platform's GUI is generally more important than wasting a few pixels. (Trees without sufficient indentation are actually really hard to follow, I think.) Really really bad idea. In an IM (or most things GUI related) anything flashing should be reserved for something that requires the users attention. In this case an event (usually a message). If you have something always flashing in the corner of your screen you are going to cause your user to be continually glancing at it. Since Jabber can only have trees one level deep, this is hardly an issue (this is still true isn't it?) Also - while I think about it - what's with not being able to have an empty group? But is it useful to display the current resource on the client? Or is it ok to just have it in the settings? It is very useful to display in the client! For example, it lets you tell at a glance whether one of your co-workers is in her office or is telecommuting from home. Sorry, I was meaning *your* current resource, not the ones of your contacts. Usually you will know if you are in the office or not. Usually for contacts, their online status is the most important thing. If you want to know their location, you can do something to look it up (hover your mousepointer for example). [Note: Your opinions may differ, I am not suggesting anyone change their clients etc etc] I think each user should be displayed only once...and events should go to the resource with the highest priority by default, but it should be possible to send to resources with lower priority. But does this include offline resources? This depends on two things that I'm frankly not sure of: * What happens if you send an IM to a specific resource which is offline? Does it bounce, does it go to the highest-priority online resource, or is it queued until that resource logs on? If the latter, then there might be a use in IM'ing an offline resource. Queued for sure would get my vote. If you send to a specific resource, obviously the intention was not for it to go to the highest online resource. Messages shouldn't bounce in Jabber. The client should provide the information at to it's online or offline status before you send. * What is the presence of a gatewayed resource like a pager or cellphone? Obviously Jabber doesn't know when you turn your phone on or off, so the presence can't update accordingly. Does the presence always get shown as available or unavailable? If the latter, there is definitely a need to be able to message such an offline resource. Hmm... Sucks why? They all suck is a little vague. Suffice it to say that my primary gripes are that they don't show rich enough status info, I'm not really sure what you mean here. They show all the status modes that the protocols support at a glance. Sure resources etc would be nice, but if the protocol doesn't support them it is hardly a client issue. and that the chat view is really impoverished (it's basically just a plain-text telnet window, maybe with some boldface or colored text if you're lucky.) Never really been much of a fan of split-screen chat's myself, but some people seem to like them. There are not many people who are going to be bothered changing fonts and word colours in a chat situation. I'm fascinated that this is important to you though. And none of them really seem to make good use of avatars (apart from the really experimental ones like The Palace.) I think avatars / buddy pictures are very important -- out in the real world a huge fraction of people think best visually rather than verbally. I agree - should be very interesting to play with them. Again though, this isn't a client issue since the protocols don't support Avatars. Also I think you are going to find that 70% of end users stick with the default Avatars, and 20% of those that customise them are going to be so annoying to you, you will want to override them at your client. Yeah, there are slight differences between AIM, ICQ, MSN, Yahoo, etc., but really they're all pretty close to being carbon copies of each other. For the most part developers are just cribbing from existing clients rather than Thinking Differently. I so don't agree with that. ICQ has so much more functionality than the others (in some case too much). I'm all for innovative designs, but at the same time it has to be balanced with what is known to work. Experimental clients are fine, but what Jabber really needs at the moment is some solid clients to compete with the commercial
Re: [JDEV] Jabber Client Design Tutorial
Don't worry, I'm not going to flame - I agree with what you're saying, but it's important to say why they (I suppose I should use the word 'we') build clients that appear ugly to a lot of people - I for one *hate* having to point and click and follow cascading menus and have my screen cluttered by silly icons. I much prefer to control an app with my main input device - my keyboard - by a combination of keystrokes or whatever. I have never been able to work out why people seem think that GUI's and keyboard commands are mutually exclusive. The closest thing that can be used as an explanation for why people think they are mutually exclusive is that in a gui environment such as Windows, you would be hard pressed to find two applications by the same manufacturer, that use the same keboard shortcuts. Some will be the same, but not all. Save is usually Alt-f s, but that is not allwaays the case. My personal favorite example is Find. Microsoft doesn't even get this one consistent. In Word and Excel, if you want to find a string of text, or a number in a document, you simply hit Ctrl-f. If you are in Outlook, (and I presume Outlook Express) Ctrl-f is 'Forward'. If you want find in Outlook, you have to hit Ctrl-Shift-f. This is getting way off topic, I'm sorry, but... I'm amazed to read this. In my opinion one of the strengths of the Windows GUI is that most of the keyboard commands are (semi)consistant. I know that 99% of the time, Cntl arrow will move a word at a time, shift-insert will paste, PgDown will scroll down, holding shift and doing any movement will select text, pressing the menu key will bring up a context menu, Alt-F4 will close the current window, Alt-tab will switch applications, Cntl-tab will move though windows within the current application etc etc.. the list goes on. Contrasting this to other operating systems I have used where there seems to be no standards, it is *very* nice. Vendors will stuff up on the odd client specific keys - and the find in Outlook is one that bugs me too, but compared to moving between commandlines on a Unix machine, or applications on OS/390 etc, it is bliss. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Peter, thanks for the reply, but I was hoping for something a bit more helpful. There seems to be a large amount of people who are prepared to stand up and say This looks like the ICQ interface which is Bad but there are more productive ways to comment. If you are going to take the time to disagree with something, at least state some reasons: Why do you prefer an IM interface that is more akin to an email client? (this is one that has always baffled me I have to admit) What advantages does it have? My primary goal in building Winjab was to essentially create a unified messaging application that could handle all kinds of messages and forums that you would normally communicate in. These forums included: - email - one on one chats with people - group chats (conference rooms) These 3 things comprised almost 100% of my daily communication modes. I designed the winjab gui such that it could easily encapsulate all of these various modes. My other goal was to eliminate the mess of windows that a system like ICQ, AOL, etc always seem to create. When chatting with 10 people, I don't want 10 top-level floating windows on my desktop. If I want to communicate, I should just be able to click on the Winjab icon in the taskbar to do whatever I need. From this standpoint, I'm not just an IM user, I'm a msging user :) Which is very different. I might want to participate in a conference, I might want to chat 1-1 with someone, or maybe I'm sending an offline msg to someone (ala email). I would actually say that the way I use winjab (where everything is docked by default) it takes up considerably less space than something like an ICQ interface would. Why? Because I almost never have less than 4 windows open at once. So in a traditional ICQ style client, I'd have my roster (1 window) plus 4 or more other windows floating on my desktop and consuming real-estate. With the winjab design, I have a single window which encapsulates all of these windows. I actually stole GUI elements from several applications when constructing the winjab GUI: - Outlook express - XChat - mIRC All of these applications (IMO) do a good job at conserving real-estate but providing a rich interface for doing different types of communicating. I may have worded the introduction badly, but I had thought I had made it clear that this document was my opinion on what I thought an ideal UI would look like, and it was not intended to be all things to all people. It is specifically aimed at the Windows desktop for one. Obviously there is a need for different style clients. I an not advocating that this is the ideal layout for a client on a mobile phone for example. I agree, that this is perhaps your ideal client... but the way many parts of your article are worded, it conveys an attitude that this should be the ideal GUI for all windows clients. In the past, Jabber has had a difficult time always conveying ideas to the community.. documents like this I think would give the newbie jabber developer the wrong impression about the community as a whole. I agree that it may be what _you_ consider a good GUI for jabber clients, but it by no means represents what the Jabber community thinks :) Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 01:36:01PM -0700, Ragavan S wrote: How is this different from 'hotkeys'(like Alt - for back on a browser, or Ctl-c to cut) that most(?) applications come with? Because there's no overhead (screen real-estate or otherwise) that's to be lost to 'useless' menus and so on. From my (perhaps limited) windows experience, there are more GUI apps that do the hotkey stuff badly than well. I guess I'm thinking of the mainframe environments I grew up with - ISPF, SDSF, and so on. Even today, I haven't seen an environment, graphical or no, to beat them. And they were 80x25 text format too. A fantastic combination of hotkeys and small commands entered on a command line. hotkeys, will soon start using the one they prefer and are used to. But, this doesn't mean the client shdn't give them the choice to do that. Absolutely. Flexibility is great. But not at any price. dj 'old-git' ISPF editor fan ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Oh, yes, I agree. We still are lacking a very good windows client. We definitely need some UI designers (who are aware of the Windows UI guidelines, by the way, and try to make the app follow them) to work with some programmers to get a really good windows client out there. The best way to start this process is with users on this list sending their detailed likes and dislikes on various clients. Sending a message that a particular client 'sucks' does not help the process. Instead an explanation, on why a particular feature is not correctly implemented or there is a better way to achieve something in the User Interface is much more productive. BTW Michael, your document was very well written. I don't think there is ONE correct UI and diversity is something to be proud of. But I hope we can use this debate to find out how Jabber clients can exceed the other clients in terms of User Experience. Regards, Ashvil ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Don't worry, I'm not going to flame - I agree with what you're saying, but it's important to say why they (I suppose I should use the word 'we') build clients that appear ugly to a lot of people - I for one *hate* having to point and click and follow cascading menus and have my screen cluttered by silly icons. I much prefer to control an app with my main input device - my keyboard - by a combination of keystrokes or whatever. I have never been able to work out why people seem think that GUI's and keyboard commands are mutually exclusive. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Thanks for the pointer Rikard. I didn't want to deviate too far from the traditional Windows interface that most people know, but I'm always interested in GUI design, so I will check out the links. I look forward to reading your ideas. Michael. - Original Message - From: Rikard Linde [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 6:00 AM Subject: Re: [JDEV] Jabber Client Design Tutorial Hi. I find your GUI example interesting in many ways. I especially like your focus on keeping the client small and unobtrusive. What surprises me is that not you or anyone in the entire software world has tried to implement Jef Raskin's Humane Interface. It is by far the most clever interface I've encountered. I'll present ideas for a jabber client based on Raskin's ideas as fast I get time to write it. If you haven't read his book I recommend it. It will completely change the way you look at interfaces. No, I'm not kidding. Raskin is the guy who designed the Macintosh and he seems to be the only person who has developed his interface ideas since the Macintosh was released. http://www.amazon.com/exec/obidos/ASIN/0201379376/qid=1001360936/sr=2-1/ref= sr_8_3_1/104-2763255-8995956 Here's something similar he wrote for Wired 1993. It's called Down With GUIs: http://www.wired.com/wired/archive/1.06/1.6_guis_pr.html Rikard _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Re: http://www.aurora.gen.nz/jabber_design
Some detailed points:* You make the point that the client should
integrate into the operating system's GUI, but then you show Mac-style flippy
triangles for the group show/hide controls on a Windows client. For it to be
Windows-like it should use the boxed "+" and "-" things that the generic
Windows tree view uses.
I looked at that. The main problem was that I
needed a three-phase icon (for when you get an event from someone in a collapsed
group), and couldn't think of anything beyond the + and -. Also, to
replicate the +/- style usually means showing the tree branches, which takes up
horizontal room, resulting in wasted pixels.
* Your list of status states in Jabber is wrong. The default is called
"Available", not "None". There is no "N/A", instead you mean "XA" ("extended
away", and I have yet to see any coherent description of how this differs from
regular "away".) Also, "invisible" is not currently supported by the Jabber
server; if you manually set your presence to "unavailable" you stop receiving
presence or messages. There's also an implicit "unknown" state for people
whose presence you don't have a subscription to (presumably because they
haven't approved your request yet.)
Noted. Thanks. The invisible issues has
been covered on this list a few times, (although I can't find it in my archives
for some reason) but the last answer I remember is that is was possible to do
some type of invisible mode now. Is this wrong?
* You don't mention one issue that bugs me about current Jabber clients.
The Jabber "resource name" is associated with a particular login. The best
usage of this is to identify the location of the client, i.e. "work" or
"laptop" or "home". For a non-PC client the type might be useful, like
"cellphone" or "T900 pager". However, whenever I look at my buddy list it
seems like most of the clients (gabber, winjab, etc.) just use the name of the
client as the resource name. This is fairly useless -- usually I don't care
what brand of desktop client they use. It is often useful to know
whether they're at home, at work, in a cafe, whatever. IMHO the client, when
first run, should ask the user to enter a resource name, and it should store
that as a persistent preference. This type-in field should not default to the
brand name of the client; it should be blank to encourage the user to type
something meaningful.
Yes, the function of the resource should be clearly
explained at the setup stage. It's a new concept in IM clients, so it does
confuse new users. But is it useful to display the current resource on the
client? Or is it ok to just have it in the settings?
* A related issue is how resources should be displayed in a client. If
someone's online at two locations do they show up as two people, or as one
person with two possible recipient addresses, or? Likewise, if someone has two
known JIDs should they show up as separate people in the list or be coalesced
into one?
I think each user should be displayed only
once...and events should go to the resource with the highest priority by
default, but it should be possible to send to resources with lower
priority. But does this include offline resources? Should you be
able to send messages to yourself at another resource?
* You might think about how the coming support for 'avatars' (pictures of
users) can be integrated into Jabber user interfaces. Where should these be
displayed? At what size? How do you configure yours? You want to give people a
range of choices. A compact buddy list(tm) is efficient, but makes photos
illegible. 64x64 photos look real pretty but take up a lot of
room.
Yes - I've been giving it some
thought.
In general I think your comments are useful, but they're not pushing the
envelope. They merely reflect the current 'best' practices of commercial IM
clients, which IMHO all suck. No one has really thought through the issues and
tried to do something better; they're all just repeating AOL's and ICQ's
mistakes.
Sucks why? "They all suck" is a little
vague.
Michael.
Re: [JDEV] Jabber Client Design Tutorial
Michael Brown [EMAIL PROTECTED] wrote: Don't worry, I'm not going to flame - I agree with what you're saying, but it's important to say why they (I suppose I should use the word 'we') build clients that appear ugly to a lot of people - I for one *hate* having to point and click and follow cascading menus and have my screen cluttered by silly icons. I much prefer to control an app with my main input device - my keyboard - by a combination of keystrokes or whatever. I have never been able to work out why people seem think that GUI's and keyboard commands are mutually exclusive. The closest thing that can be used as an explanation for why people think they are mutually exclusive is that in a gui environment such as Windows, you would be hard pressed to find two applications by the same manufacturer, that use the same keboard shortcuts. Some will be the same, but not all. Save is usually Alt-f s, but that is not allwaays the case. My personal favorite example is Find. Microsoft doesn't even get this one consistent. In Word and Excel, if you want to find a string of text, or a number in a document, you simply hit Ctrl-f. If you are in Outlook, (and I presume Outlook Express) Ctrl-f is 'Forward'. If you want find in Outlook, you have to hit Ctrl-Shift-f. In BeOS, just about eery app I have seen uses Alt-f for find, but the most intuitive keystorke to exit that dialog, specifically Esc, does not exit the dialog, it presumes that you are looking for some character mapped to that key on the keyboard. Life has been a little easier in the Macintosh world where if you wanted to sell your application and get Apple approved, or Apple recomended, you built your application to the Apple guidelines for keyboard commands. The main problem in my opinion is that there is no standard keyboard command set specifying reserved keyboard commands. About the closest I have ever seen to an effective solution was the BlueWave editor, where you could tell the editor what standard application keyboard commands you wanted to use. If you prefered Wordstar commands to EMACS, or EPM over BP7-IDE, you could specify the appropriate keyboard command set to use. The easy way to accomplish this is to establish the commands that you want the application to use, set up your own keyboard command mappings in a loadable text file, and allow users to create their own. Then allow users to send you their keyboard command files for inclusion in later releases of your software. Of cours all of this is accademic if your users do not like the interface you present, they should look for another interface that they do like. If you can present different interfaces within your application, either via skins that do more than just provide colorful backgrounds and buttons as an overlay to the existing interface, so much the better for your application. One thing to take into consideration when telling people that their criticism is less than what you are looking for is to give some examples of why you find their criticism that way. Saying, you have to do more than say 'I don't like this. you need to tell me what about it you don't like. is about as helpful as the orriginal criticism. As an example, an appropriate response to your request for further feedback might be I don't like this, the colors you have selected make me nausous. yet all you know now is that the user was not the least bit concerned about the fact that all your 3D-buttons appear to be lighted from above and to the left. The solution could be to use the user customized appearence for Windows, or if you do letting the user know how to go about changing that appearance. If someone preferes a different interface format, it is often because they think of IM in a different way than you do. From what I have seen of ICQ, The UI is based upon the concept of a list of friends, that you can either send a message to or chat with. I realize that there is much more behind it, but that seems like the simpelest explanation of what you can do, and what you generally see. WinJabber looks more like a mail client where you have a list of friends, a collection of messages that you have recieved, and a window pane to view those messages. Again there are many more features that I will not go into. I would suspect that the primary difference is that the designer of the WinJabber client thinks of messages comming into the client as similar to e-mail messages. They contain a To field, a From field, possibly a Subject field, and a message body. Looks like an e-mail message of some sort to me as well. Note that this also means that the designer could extend his application to handle e-mail with very little in the way of changes to the UI. Is this The Right Way? No. It is A Right Way. Your concept is A Right Way as well. My definition of A Right Way is that using that method you can get the job done. Some people like jumping through
Re: [JDEV] Jabber Client Design Tutorial
Julian (x-virge) and I were discussing client design yesterday and I think you are a prime example of our discussion. There is a problem with Jabber, in general it's not everyones first IM client. Great! I've always wanted to be a prime example :-) It's true I guess, but it's not the only reason that people are turned off Jabber. Really, the Jabber clients are very immature compared to the clients for the commercial services. This is not meant as any disrespect to the client authors - none of them have the resources of AOL or Microsoft behind them, but this doesn't matter to the end user. To convince them to switch services, the clients have to be at least 90% as good as the one they are switching from. Also, the argument about switching from one of the proprietary services also applies to switching between Jabber clients, so it would be nice to have some sort of consistency between them if possible. Users have generally been on another large network (AIM, ICQ, MSN, Yahoo!) before they come to Jabber. Despite their not liking the system (that's why they came to Jabber isn't it? ;-]) they tend to like their client, usually because they are comfortable with it. That's true in some cases. My reason for wanting to move from ICQ to Jabber is more political than dissatisfaction with ICQ in the first place. I would prefer that Jabber would become a system that attracts users by what it has to offer, rather than just waiting for people to get sick of their existing system. If i had to guess, by reading your doc (which I did), you come from ICQ. If you had read my doc there should be no guessing involved. I am clearly biased toward the ICQ interface as I have said since it is the one I have used the longest (as it was the first one available), but that is not to say that I have never used any other products. I use Lotus Sametime all day at work, and have MSN installed. At the moment I am using Go Messenger as my Jabber client, and have used JabberIM quite a lot. Now I say this with absolutely no direction to you, but I find ICQ's UI absolutely atrocious, even AIM's is pretty wicked, so is Yahoo!, MSN is partially acceptable, but has many disparities. I say all that from a purely UI centric view. I was hoping for something a bit more substantial I have to admit. Saying xyz is atrocious is not really productive, unless you can back up your opinion with examples, and better options. ICQ's interface is a bit confusing for a first time user, I have to admit, but for power users it is great. AIM and MSN are much more basic clients, since their services lack many of the features that ICQ and Jabber offer - such as offline messages - but there are things that we can and should learn from them. The idea of a doc to help get people rolling beyond the protocol is a great idea and there are many odd things about Jabber that merit UI discussion (iq:browse, it could easily have a browser view like winjab, but could also be a simple tree view like the explorer sidebar), but I would encourage you to weigh in many options, not a single view. Sure - more opinions the better - that's the whole aim. That and to give client developers ideas that they may not have thought of. Client design doesn't have to be as black and white as the protocol, but there are definitely some rules you should go by. Let me look into iq:browse, I'm not exactly sure how it is used or the best way to present it. Open it up, and don't suggest that only one thing is correct, because you never will please everyone, especially in the IM world. Never aim to please everyone... Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
I, of course, agree with temas here. I have quite a few comments already, but I'll look at your guide a bit more thoroughly tomorrow and make a reply. Thanks, that would be great. One major thing that struck me was that you said server hard disk space won't be wasted by history. Did I? Depends on what you mean by wasted I guess. Data is going to take some space obviously. I will go back and review that section actually. I cut and pasted it from an old note and maybe it could be better worded. It's not really a UI issue, I just wanted somewhere to put my rant. My main point, is that the history should not be saved locally. My logs from the past two years total 50 megs. Really? My ICQ history database for the last 4 years is only 20MB (more once it's indexed). Have you tried zipping it? 50 megs... 100 000 users on a server. Even 10 000 users on a server. Would you care to pay for that much disk space? Nope, but I'd be happy to pay for 50MB for my own account. I think you miss my point(s) somewhat... - It doesn't actually have to be on the same physical machine, just somewhere that all clients can access it. - It doesn't have to be enabled on every server, or it can be an optional (chargeable) feature. - Admins can fix a limit to archive sizes - most people won't want to refer to a chat session 4 years old. - Not all people will want to save message history. - Disk space gets cheaper every year. - The advantages outweigh the storage issues. And remember, these messages are all plain text. Just wait until we have rich text formatted messages. Good point...I was thinking that ICQ was rich text, but looking at it now, it just seems to save the font and colours. I guess there are a few options - wear the extra resources, or convert to plain text maybe. I wouldn't get hung up on the space issue... A good design is more important at this stage. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 09:53:46PM +1000, Michael Brown wrote: I'd have to respectfully disagree there... I don't want a one-size-fits-all world, and I relish the diversity of clients available right now. I didn't mean to imply that they should all be the same, but there is some need for *some* clients that behave in a similar manner, and provide the same function as the commercial clients in order to convert the general public. True. I just thought it necessary to make sure my stick was still firmly in the mud. :-) dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Hi. I find your GUI example interesting in many ways. I especially like your focus on keeping the client small and unobtrusive. What surprises me is that not you or anyone in the entire software world has tried to implement Jef Raskin's Humane Interface. It is by far the most clever interface I've encountered. I'll present ideas for a jabber client based on Raskin's ideas as fast I get time to write it. If you haven't read his book I recommend it. It will completely change the way you look at interfaces. No, I'm not kidding. Raskin is the guy who designed the Macintosh and he seems to be the only person who has developed his interface ideas since the Macintosh was released. http://www.amazon.com/exec/obidos/ASIN/0201379376/qid=1001360936/sr=2-1/ref=sr_8_3_1/104-2763255-8995956 Here's something similar he wrote for Wired 1993. It's called Down With GUIs: http://www.wired.com/wired/archive/1.06/1.6_guis_pr.html Rikard _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
DJ, Don't worry, I'm not going to flame - I agree with what you're saying, but it's important to say why they (I suppose I should use the word 'we') build clients that appear ugly to a lot of people - I for one *hate* having to point and click and follow cascading menus and have my screen cluttered by silly icons. I much prefer to control an app with my main input device - my keyboard - by a combination of keystrokes or whatever. How is this different from 'hotkeys'(like Alt - for back on a browser, or Ctl-c to cut) that most(?) applications come with? I'm not saying this to be obtuse - it's the truth (and why I use mutt exclusively and still use sjabber on many conferences) and any UI design that excludes this point of view runs the risk of missing something fundamental. The group of people who feel most at home with a Unix command line and all the tools that such an environment comes with (including the ones with these 'ugly' UIs) may be a minority, but it's a damn huge minority. However, what you raise here, is the bigger point of flexibility. Allowing 2/3/.. different ways to do the same thing may seem to be a bit of an overkill to most app developers and GUI designers, but it could well be the criteria some end users use to say Yay or Nay to their client. Also, most users, given the option of say, either pointing and clicking or using hotkeys, will soon start using the one they prefer and are used to. But, this doesn't mean the client shdn't give them the choice to do that. Regards, Ragavan _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Monday, September 24, 2001, at 01:00 PM, Rikard Linde wrote: [Jef] Raskin is the guy who designed the Macintosh This is way, way off-topic, but Raskin did not design the Macintosh. He was the one who originally proposed and championed building a small, all-in-one, easy-to-use "appliance" computer with a GUI, and he gave it its name. But he left Apple in '81 or '82, years before the Mac shipped, and he didn't play much of a role in the actual engineering or HI design of the Mac product. I haven't read Raskin's book, but most of the other things I've read by him give me the impression he's a rather embittered guy with a lot of ideas that I, frankly, consider pretty wacko. If I'm going to read manifestoes by user-interface cranks, I'll take Ted Nelson any day -- his "Computer Lib / Dream Machines" totally changed my life in 1979. Jens
Re: [JDEV] Jabber Client Design Tutorial
First off, I don't believe in the idea of having similar-looking Jabber clients. It would be nice to have a defacto client for each OS which looks and acts similarly, but beyond that, I want creativity to shine. I want to see different approaches at IM, not 20 VB clients for windows which look and act *exactly the same* - what's the point in that? Replies within. Jens Alfke wrote: * Your list of status states in Jabber is wrong. The default is called Available, not None. There is no N/A, instead you mean XA (extended away, and I have yet to see any coherent description of how this differs from regular away.) Also, invisible is not currently supported by the Jabber server; if you manually set your presence to unavailable you stop receiving presence or messages. There's also an implicit unknown state for people whose presence you don't have a subscription to (presumably because they haven't approved your request yet.) Actually, latest jabberd does support invisible. * You don't mention one issue that bugs me about current Jabber clients. The Jabber resource name is associated with a particular login. The best usage of this is to identify the location of the client, i.e. work or laptop or home. For a non-PC client the type might be useful, like cellphone or T900 pager. However, whenever I look at my buddy list it seems like most of the clients (gabber, winjab, etc.) just use the name of the client as the resource name. This is fairly useless -- usually I don't care what brand of desktop client they use. It /is/ often useful to know whether they're at home, at work, in a cafe, whatever. IMHO the client, when first run, should ask the user to enter a resource name, and it should store that as a persistent preference. This type-in field should not default to the brand name of the client; it should be blank to encourage the user to type something meaningful. According to all statistics I can get ahold of and from various small user tests - people do *not* easily understand the concept of a resource unless they specifically intend to be logged in multiple times - and *most* users never use that feature of Jabber. Therefore, 'Gabber' is the default resource to reduce confusion - if the user doesn't understand it, they don't have to become frustrated trying to figure out what is going on. They can live happily without know what a resource is. That's the entire point of the MacOS HI guideline which states that options are nice, but you *must* *have* *good* *defaults*. If in the future the majority of users need to understand the concept of a resource, I'll gladly remove the default, but the point of UI is to reduce the amount of information a user must learn and retain. I need sleep Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On 24/09/2001 at 9:57 PM Julian Missig wrote: First off, I don't believe in the idea of having similar-looking Jabber clients. It would be nice to have a defacto client for each OS which looks and acts similarly, but beyond that, I want creativity to shine. I want to see different approaches at IM, not 20 VB clients for windows which look and act *exactly the same* - what's the point in that? agree 100% According to all statistics I can get ahold of and from various small user tests - people do *not* easily understand the concept of a resource unless they specifically intend to be logged in multiple times - and *most* users never use that feature of Jabber. Therefore, 'Gabber' is the default resource to reduce confusion - if the user doesn't understand it, they don't have to become frustrated trying to figure out what is going on. They can live happily without know what a resource is. That's the entire point of the MacOS HI guideline which states that options are nice, but you *must* *have* *good* *defaults*. But, even if a user doesn't intent to log on multiple times simultaneously, a description of where they are currently logged in from is still useful. Surely it is clear to a user that they are entering a description of what computer they are logging in from and when they look at another user in their roster they can see where they are logged in from?... even if they don't understand the concept of resources and how they interact. If I gave a Jabber client to an inexperienced Jabber user and it said enter a description of where you are connecting from, they would enter Home or Laptop or something and then they would never have to worry about it again. Julian (the other one) ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Julian Fitzell wrote: On 24/09/2001 at 9:57 PM Julian Missig wrote: But, even if a user doesn't intent to log on multiple times simultaneously, a description of where they are currently logged in from is still useful. Surely it is clear to a user that they are entering a description of what computer they are logging in from and when they look at another user in their roster they can see where they are logged in from?... even if they don't understand the concept of resources and how they interact. If I gave a Jabber client to an inexperienced Jabber user and it said enter a description of where you are connecting from, they would enter Home or Laptop or something and then they would never have to worry about it again. Julian (the other one) Well, in the few tests I did, whenever I asked for something like that, they would turn around and ask me if I meant their country or their city or what. However, this was most likely an issue of wording which deserves further investigation. Asking the user to enter a description of where they're connecting from doesn't solve very much since they still don't get a complete understanding of resources. Also keep in mind that nowhere does it state that a resource must be a physical location. If I'm running multiple clients on one machine, I think it would be useful to know which two clients they are using. What happens if the user sets up, say, sjabber and Gabber on their machine, and both clients follow this question format? The user might enter Home into both clients - hey, they're both at the same location, why would you want to give them different locations, it's the same machine, even! Then the user would not understand why they cannot connect with both at the same time, and you have to force feed them the description of a resource, and maybe they'll get it - maybe they won't and just go on thinking you can only connect once with one Jabber account. Not to mention that fact that I'm not particularly a fan of always using a resource to describe location. It describes your session in a unique way from the others. In the future, multiple Jabber sessions from one physical location will become more and more common. Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] Jabber Client Design Tutorial
I think the concept of this document is fantastic and extremely important. Whilst a lot of us involved in Jabber might not be particularly interested in UI's, it is probably more important to Jabber's success in the short term than the server. I say this only because it's very frustrating and disappointing to see supposedly informed tech writers slag off Jabber because of a client app they downloaded and couldn't figure. TechTV, gave jabber a 1 star. They didn't even mention the server, cause to the end user it doesn't mean anything. No need to preach here, cause we're all believers. But if we can start to foster some UI what ifs discussions (maybe here, maybe not) and start to think from the end users point of view, whether they be students, parents, newbie's, business, etc, then when asshole's like TechTV do a review they will see a number of clients that get their little brains thinking. Sorry, but I couldn't believe it when I saw Jabber get a one star and other useless crap out there get 5's. I'm going to start working on some designs for clients to get some comments from everyone. Anything that gets us thinking about the end user and how they use Jabber is a good thing. Keep up the great work guys. cheers, Darren -Original Message- From: Julian Missig [mailto:[EMAIL PROTECTED]] Sent: Monday, September 24, 2001 6:57 PM To: [EMAIL PROTECTED] Subject: Re: [JDEV] Jabber Client Design Tutorial First off, I don't believe in the idea of having similar-looking Jabber clients. It would be nice to have a defacto client for each OS which looks and acts similarly, but beyond that, I want creativity to shine. I want to see different approaches at IM, not 20 VB clients for windows which look and act *exactly the same* - what's the point in that? Replies within. Jens Alfke wrote: * Your list of status states in Jabber is wrong. The default is called Available, not None. There is no N/A, instead you mean XA (extended away, and I have yet to see any coherent description of how this differs from regular away.) Also, invisible is not currently supported by the Jabber server; if you manually set your presence to unavailable you stop receiving presence or messages. There's also an implicit unknown state for people whose presence you don't have a subscription to (presumably because they haven't approved your request yet.) Actually, latest jabberd does support invisible. * You don't mention one issue that bugs me about current Jabber clients. The Jabber resource name is associated with a particular login. The best usage of this is to identify the location of the client, i.e. work or laptop or home. For a non-PC client the type might be useful, like cellphone or T900 pager. However, whenever I look at my buddy list it seems like most of the clients (gabber, winjab, etc.) just use the name of the client as the resource name. This is fairly useless -- usually I don't care what brand of desktop client they use. It /is/ often useful to know whether they're at home, at work, in a cafe, whatever. IMHO the client, when first run, should ask the user to enter a resource name, and it should store that as a persistent preference. This type-in field should not default to the brand name of the client; it should be blank to encourage the user to type something meaningful. According to all statistics I can get ahold of and from various small user tests - people do *not* easily understand the concept of a resource unless they specifically intend to be logged in multiple times - and *most* users never use that feature of Jabber. Therefore, 'Gabber' is the default resource to reduce confusion - if the user doesn't understand it, they don't have to become frustrated trying to figure out what is going on. They can live happily without know what a resource is. That's the entire point of the MacOS HI guideline which states that options are nice, but you *must* *have* *good* *defaults*. If in the future the majority of users need to understand the concept of a resource, I'll gladly remove the default, but the point of UI is to reduce the amount of information a user must learn and retain. I need sleep Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Oh, yes, I agree. We still are lacking a very good windows client. We definitely need some UI designers (who are aware of the Windows UI guidelines, by the way, and try to make the app follow them) to work with some programmers to get a really good windows client out there. But that's completely different from having an official Jabber specification stating that all clients must be ICQ. Even an informal one, I don't agree with. All it takes is one really good Jabber client, then the rest are free to do what they want, we can all point toward the one we like. Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] Darren McVean wrote: I think the concept of this document is fantastic and extremely important. Whilst a lot of us involved in Jabber might not be particularly interested in UI's, it is probably more important to Jabber's success in the short term than the server. I say this only because it's very frustrating and disappointing to see supposedly informed tech writers slag off Jabber because of a client app they downloaded and couldn't figure. TechTV, gave jabber a 1 star. They didn't even mention the server, cause to the end user it doesn't mean anything. No need to preach here, cause we're all believers. But if we can start to foster some UI what ifs discussions (maybe here, maybe not) and start to think from the end users point of view, whether they be students, parents, newbie's, business, etc, then when asshole's like TechTV do a review they will see a number of clients that get their little brains thinking. Sorry, but I couldn't believe it when I saw Jabber get a one star and other useless crap out there get 5's. I'm going to start working on some designs for clients to get some comments from everyone. Anything that gets us thinking about the end user and how they use Jabber is a good thing. Keep up the great work guys. cheers, Darren ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
But, even if a user doesn't intent to log on multiple times simultaneously, a
description
of where they are currently logged in from is still useful. Surely it is clear to a
user that
they are entering a description of what computer they are logging in from and when
they look at another user in their roster they can see where they are logged in
from?...
even if they don't understand the concept of resources and how they interact.
If I gave a Jabber client to an inexperienced Jabber user and it said enter a
description of where you are connecting from, they would enter Home or Laptop or
something and then they would never have to worry about it again.
Julian (the other one)
Well, in the few tests I did, whenever I asked for something like that, they would
turn
around and ask me if I meant their country or their city or what. However, this was
most
likely an issue of wording which deserves further investigation. Asking the user to
enter a
description of where they're connecting from doesn't solve very much since they still
don't get a complete understanding of resources.
One way around all this would be a set of suggestions for reasonable resource strings.
WinJabber does this with a pulldown. I have not tried entering my own in there as
Laptop just about describes what I am working with at the time.
If you are running a logging client, to capture your IM's that are not cached
elsewhere,
'Logging seems reasonable to me. If it is important to you that people know whether
you are at work (work), home (home), at a convention (peer.networking), or sitting in
the
middle of the lake pulling in walleyes (occupational.rehabilitation), you could select
or
create an appropriate resource for that. You could even have a resource that would
capture IMs and forward them to your text pager or digital cell phone with a resource
name pager.
While a well written application should be intuitive, and not require the user to
spend an
inordinate amount of time looking up explanations for what is expected in different
fields,
sometimes it makes sense to provide redily available help or suggestions for each
field
as well.
For clients that perform services for you, either as avatars, such as a jabber
callendar
client which could im a pager client to remind either yourself or a peer that it was
time
for a meeting, or to pick up something for your aniversary before you got home, or a
pager type client that is inbound only, it would make sense to have pre-defined
resources that other clients would recognize, and treat appropriately.
In any case, a first time user is not going to know intuitively what some of the more
arcane resource names mean. If they are using WinJabber, how likely is it that they
will
recognize that the resource Marvin could be an indication that the user of the
Marvin
jabber app (A fully skinable Jabber client for Windows written in Euphoria) decided
not
to enter a custom resource {presuming that 'Marvin were the default resorce for that
app, I don't know.} They might just think the user is having a particularly bad day
with
pains running up and down their left arm, and mistakenly try to cheer the user up.
Just some ideas.
Others include using 'services' numbers or names for resources if they are specific to
some service. 25:smtp for a mail service, 79:finger for a response about the user,
(other
than a vcard) 80:http for the users home page, or hot link of the day, or whatever.,
444:snpp for paging, 533:netwall for emergency broadcasts 555:whoami for a response
based upon pulling down the vcard of the person contacting that resource, and the
like.
Resources for services available in clients could be shown either by service name, or
number, and user clients could be designed to ignore those resources unless the user
is in
some advanced mode. I would suspect that properly written service clients would
discard messages that were improperly formated, or log them to some sort of a syslog
resource some place.
A user manager client could be created as part of a user client, and it would look
for
resources for users that have agreed to notification both ways, and depending upon
each user's paranoia index can either add those contacts to the local facilities, or
make
available similar resources to the other user. I think it could work something like a
shared
callendar where some events are not available to other users of the shared callendar,
some are only I am unavailable for this block of time events (my peers do not need
to
know that I have to take my cat into the vet, but they probably shouldn't attempt to
schedule a meeting for me while I am there.) And others are fully shared, I will be
involved in the annual review of all of your budgets today, do you really want me
upset?
Likewise I may want my pager available for co-workers and supervisors, but not for the
jokers I quaf a few with every wednesday night.
-Rusty
Re: [JDEV] Jabber Client Design Tutorial
I've been reading this list for about a month while slowly writing a 'Jabber Client'. I do believe UI is important, but my client doesn't have one yet. Actually my client is a module for a webserver called AOLserver. I am late coming to Jabber. I first found out about it from an article in _Linux Magazine_, August 2001! It was enough for me it seriously consider the usefulness of this technology. I don't need to sell that here, but what I would like to sell is the usefulness of exposing the jabber packets to a programming environment that is easy to use, and that would support module like applications. What I have done so far is to create a C module for AOLserver that uses the libxode and libjabber api. This api is exposed to the scripting environment of AOLserver which is TCL. The individual xmlnodes which represent the jabber packets are passed into the scripting environment as well. From this point, the programmer is free to handle the packets however they wish. I'm sure this is similar to the perl api, but there are differences. AOLserver is a multi-threaded, general purpose server. It has a complete database api, it is a high performance webserver. Although Apache is a very good webserver, Jabber requires a continuous connection and shared memory to be effective. My initial ideas of using jabber were merely as a way of delivering messages from a website. I quickly realized that writing a bot was not that difficult with this client. Today, while reading this thread, I realized that AOLserver could serve as a nice user client, not just a client for a webserver. My reasoning was simple: AOLserver has too large of a footprint to directly serve many users, but it is small in relation to most GUI software. The client software could be installed on a user's personal machine, or on a firewall. The user would then connect to the client using a web browser. Since AOLserver is a general purpose server, there is even the possibility of connecting a display client, instead of a browser. Obviously it would be realtively easy to integrate any oob needs into this type of setup. I have a simple three function bot that answers to [EMAIL PROTECTED]/ws. It is hardly an ideal bot, but it demonstrates that you can easily add module like functions in a simple way. I hope this was not too off topic, but the UI is an extremely labor intensive process. If significant functions can be added without the constant need to worry about the UI programming, it might speed up use of Jabber as a technology. --Tom Jackson ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Monday, September 24, 2001, at 07:25 PM, Julian Fitzell wrote: If I gave a Jabber client to an inexperienced Jabber user and it said enter a description of where you are connecting from, they would enter Home or Laptop or something and then they would never have to worry about it again. That's what my client does. It describes the resource name in about one sentence and gives Home, PowerBook and Naomi's Office as typical examples. Most people testing it manage to figure this out pretty well. Also, once people are actually using the client and see the resource names next to their buddies' names, they get the point and sometimes clean up their own resource name if they put in something awkward originally. --Jens ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] Jabber Client Design Tutorial
In an effort to generate some debate, and give people some ideas when designing Jabber clients, I have put together a brief tutorial document which is up on my site. http://aurora.gen.nz/jabber_design/ Can I ask some people who are more familiar with the Jabber protocol to take 5 minutes and read though it to make sure I am not advocating anything that is impossible with the current Jabber spec, or if there is anything too obvious that I haven't included. Also, it's something of a first draft, so if anyone has good ideas to add, or things that they think should really be changed, please let me know. Feedback to the jdev list or direct email is fine. The document is intended as an illustrated guide to GUI design, and doesn't contain any programming specific details. Can someone also tell me how I can get a link added to the docs section on jabber.org? Thanks, Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
