On Thu, Sep 02, 2004 at 12:48:39AM -0500, Nolan Eakins <[EMAIL PROTECTED]> wrote: > Lucas Nussbaum wrote: > > 1) Jabber is a difficult technology. It is very difficult for end users > > to understand what it's all about. I think we lack a good documentation > > for end users, covering stuff like what is a Jabber server, a JID, can I > > communicate with users on other servers, etc ... Or I haven't found > > it yet. If such a documentation exists, it would be interesting to start > > a translation project, so Jabber-related websites could use localized > > versions. > > Does email have good documentation? If you're online, you know what email > is. Why? Because any ISP will give you at least one email address to use, > and then name off a couple of email programs to use and how to set them up. > If an ISP gave you a Jabber account to use, presumably it'll be the same as > your email. So JIDs and what is a Jabber server wouldn't need to be > documented for the end user.
Email can be understood with real world experience since it has a lot of similarities with snail mail : email address <-> postal address mailbox <-> mailbox etc but what about : jabber server ? transports ? Currently no ISP gives Jabber accounts. So what we have to deal with is users who decided to use Jabber, and those users need to grasp far too many concepts. > So why aren't ISPs giving out Jabber accounts yet? That's gotta do with the > state of our code-bases. An ISP isn't going to setup a buggy, incomplete, > and hard to manage server. They need the equivalent of an Apache, something > they do setup and use. I think a poll would be nice here. I think you are one step too far with this ISP story : ISPs don't see the need for jabber servers since nobody uses Jabber. And nobody uses Jabber because it is difficult to grasp and poorly documented. > > 2) The number of clients/libraries/servers. For somebody coming to > > Jabber, it is very difficult to choose a client. There's no comparative > > charts saying "this one does this, but doesn't do this, etc ...". There's > > http://www.jabber.org/software/clients.php, but I find it quite useless. > > There's the same problem for libraries. There are for example 4 > > different libraries in python (jabberpy, xmpppy, pyxmpp, twisted). How > > do they compare with each other ? > > Tell your friends I use this client. Set it up for them. Get them to use it. > If they like it, they won't go looking for a new one. If they do go > looking, maybe they'll find something better or worse. Word of mouth should > be good, except for the isolated adventurer. This way to work doesn't scale well. People should have other (easy) ways to choose a client than asking their neightboors. > Though client reviews won't hurt. Contribute them to Linux Journal or > something. It would get the word out too which results in people doing > what's described in the above paragraph. Still, probably a bit too technical : we would miss our target. > > B. do something like the Apache Software Foundation : best > > clients/libraries/servers should be endorsed by the JSF, so users would > > be able to choose between a restricted number of > > clients/libraries/servers. Of course, criterias for the selection should > > include things like : - the code must be documented. > > - the licence must be free. > > - stuff like a public CVS, a bugzilla, etc ... must be available. > > See jabberstudio.org. It could be improved to point people towards specific > projects. I know SourceForge.net does more than just host projects (ie: > Most active, popular, etc.). See http://www.apache.org/. 50% of the projects on jabberstudio.org are either unmaintained or dead. Don't get me wrong, this is great : people do experience with Jabber a lot. But still, people don't want to test 20 clients before finding one that suits their needs. So a list of usable clients/libs/components/servers, with their features, would be great. > > All those ideas are non-technical work. I think that technical work has > > proven to be unsuccessful with solving the jabber community problems. > > I'll beg to differ on that point. The lack of technical work is the problem. > If tech work was unsuccessful, stpeter's mantras wouldn't all be "...more > code". They would be "Less code, more process". Anti-mantra #1. :-) To summarize : Problem: "There a too many unusable or undocumented clients/servers." Solution: "Let's do another one !" Does it sound right ? -- | Lucas Nussbaum | [EMAIL PROTECTED] [EMAIL PROTECTED] GPG: 1024D/023B3F4F | | jabber: [EMAIL PROTECTED] http://www.lucas-nussbaum.net | | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F | _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
