?

Log in

No account? Create an account
Update - LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Update [May. 4th, 2002|09:20 pm]
LiveJournal Client Discussions
lj_clients
[xenofalcon]
As you may or may not have noticed, the Client Download Page has recently been updated. Hopefully all operational clients have been included. If you have a (working) client and want to be listed on the page, please leave a comment to this entry mentioning it.

I would also like to incite some important discussion about clients and LiveJournal. As LiveJournal is expanding, more and more clients are being released to the public. This is a great thing--more and more platforms are being supported and users are being given a greater number of choices in how they can interact with their journal. But, with numbers comes complexity, and we want to make this easy for the users.

Firstly, should it be recommended that every client author create a journal/community for their client? Users can be kept informed of updates through their friends list this way, among other things (mentioned below). A centralized place on LiveJournal for official information regarding the client in question should be preferred to an off-site page, if only for contiguity.

Secondly, and directly related to my first point, should all client journals/communities be permanent accounts? There is no rhyme or reason to the current setup, as some are perm, some are paid, and some are free. There isn't any benefit to making them permanent, really.

Thirdly, should version updates be posted in this community? Technically, there are better places to post such announcements, as most viewers of this community aren't the end users that authors are trying to inform, but mainly developers. This goes back to the first point.


This next part is more of a suggestion to all client authors, rather than open questions to the community.

Support for end-users needs to be discussed. Technically, the only three clients that Support offers help with are the Web client, the Semagic client, logjam, and the Win32 client. Given this, probably the best way to support those that are using your client is to keep an open community, where users can go to each other for support. If nobody else can help, then you can directly help them; this way you won't have to answer the simple questions yourself. Community posting is also a great way to hash out bug reports, as users can post "me too" messages, helping you isolate the cause of odd bugs. Along the same lines, you can get a good feel for what features your users desire.

If your client is popular enough, you've undoubtedly received emails asking for invite codes; perhaps it would be a good idea to incorporate messages into your client informing the user that if they do not have a LiveJournal, then they must get an invite code from a current user, and that the author will not give out any. A note on the downloads page might help too.

Thoughts? Questions? Comments?
linkReply

Comments:
[User Picture]From: rahaeli
2002-05-04 06:29 pm (UTC)
Personally, I think that Support should be offering first-tier support either for all clients or for no client. There are very few problems that can't be solved by someone who is an experienced user of that client, and most privs are more than aware of when it's time to get in touch with someone who had a hand in developing it.

If we offer support for some clients and not for others, it only leads to problems.

And besides, the authors of the clients have MUCH better things to do than monitor their communities for "d00d why can't i make text bold in your client??!?!?" :)
(Reply) (Thread)
From: asciident
2002-05-04 06:38 pm (UTC)
Personally, I think that Support should be offering first-tier support either for all clients

I'd like to say that as long as it's allowed by Support policy and the developer has not specified otherwise, I'm happy to offer support for all clients (that I can support!).
(Reply) (Parent) (Thread)
[User Picture]From: rahaeli
2002-05-04 06:47 pm (UTC)
Ditto, and I think that a lot of people agree. I know that I've been handling Mac client requests that come through the support board for a while :)

We have a number of clients offered for download -- the download page just keeps getting bigger. If we offer support for Logjam, the Win32 client, the Win32-Sema client, and the Web client, I think that we should be offering support for all of them. Otherwise, the user comes to the support board and gets told 'oh, we don't support that' -- even though they downloaded the client from an official LJ page.

It's a bad user experience, and we should be avoiding those at all costs. Especially when it's something so simple as instructions on how to get the client running.
(Reply) (Parent) (Thread)
From: asciident
2002-05-04 06:50 pm (UTC)

Re:

Exactly.

(And if there's *nix support (which receives almost no legitimate requests), there damn well ought to be Mac support!)
(Reply) (Parent) (Thread)
[User Picture]From: rahaeli
2002-05-04 06:51 pm (UTC)
I've been arguing this for a while, if only so that people who don't USE the Mac client can use Highway's thingy to check back over old requests on the same problem and see how they were handled. I'd really like to not be the only person doing Mac support :)
(Reply) (Parent) (Thread)
From: asciident
2002-05-04 06:52 pm (UTC)

Re:

Heh, true. We might have to tie you to the board in case you ever try to leave if we don't get more Mac-knowledgeable privs. ;)
(Reply) (Parent) (Thread)
From: xenofalcon
2002-05-04 06:55 pm (UTC)
Damn. I would get privs rather quickly if we had a Mac category. ^_^
(Reply) (Parent) (Thread)
[User Picture]From: rahaeli
2002-05-04 07:00 pm (UTC)
Funny, i've been told that before :)
(Reply) (Parent) (Thread)
From: scientaestubiqu
2002-05-04 07:08 pm (UTC)
I'd actually like (but I know I'm dreaming) another pull down menu added to the support request form... maybe not mandatory, but every little bit helps...

Platform: Windows, Mac, Linux, Unix, Other etc etc...
Browser: IE, Netscape, Opera, iCab, Other etc...

I'd love to be able to filter by platform and browser type...
(Reply) (Parent) (Thread)
[User Picture]From: rahaeli
2002-05-04 07:11 pm (UTC)
I think it's been proposed, actually. I know i'd love it too.

But this has gotten seriously off-topic from clients :)
(Reply) (Parent) (Thread)
From: scientaestubiqu
2002-05-04 09:22 pm (UTC)

true...

and I would know that if they hadn't taken away my "parent" link *sob*
(Reply) (Parent) (Thread)
From: asciident
2002-05-04 08:53 pm (UTC)

Thought I'd address this as a client developer...

...since SharpJournal is about to be released as a beta.

Firstly, should it be recommended that every client author create a journal/community for their client? Users can be kept informed of updates through their friends list this way, among other things (mentioned below). A centralized place on LiveJournal for official information regarding the client in question should be preferred to an off-site page, if only for contiguity.

As you know, SharpJournal already has a community.

Secondly, and directly related to my first point, should all client journals/communities be permanent accounts? There is no rhyme or reason to the current setup, as some are perm, some are paid, and some are free. There isn't any benefit to making them permanent, really.

I personally don't care if the community is ever made paid/perm. I might buy it 2 months worth to make a nice style for it.

Thirdly, should version updates be posted in this community? Technically, there are better places to post such announcements, as most viewers of this community aren't the end users that authors are trying to inform, but mainly developers. This goes back to the first point.

All things related to the client will be (ideally) posted there. After the first final version is released, the community will become open. (As you know, it's closed at this time to deal with first-beta topics.)

Support for end-users needs to be discussed. Technically, the only three clients that Support offers help with are the Web client, the Semagic client, logjam, and the Win32 client. Given this, probably the best way to support those that are using your client is to keep an open community, where users can go to each other for support. If nobody else can help, then you can directly help them; this way you won't have to answer the simple questions yourself. Community posting is also a great way to hash out bug reports, as users can post "me too" messages, helping you isolate the cause of odd bugs. Along the same lines, you can get a good feel for what features your users desire.

If SharpJournal ever has a support request opened for it, I'm more than happy to answer it, as I'm sure Karl is as well. If anyone else wants to knowledgeably answer it, too, then by all means go ahead. :)

If your client is popular enough, you've undoubtedly received emails asking for invite codes; perhaps it would be a good idea to incorporate messages into your client informing the user that if they do not have a LiveJournal, then they must get an invite code from a current user, and that the author will not give out any. A note on the downloads page might help too.

Already planned.
(Reply) (Thread)
[User Picture]From: cryo
2002-05-05 05:44 am (UTC)
If your client is popular enough, you've undoubtedly received emails asking for invite codes; perhaps it would be a good idea to incorporate messages into your client informing the user that if they do not have a LiveJournal, then they must get an invite code from a current user, and that the author will not give out any. A note on the downloads page might help too.

Feh. Requiring a code on a new client install is self-defeating. I've bitched about this far too much. I've got the stats showing numerous downloads for installs, but not anywhere near the number that are using it. This implies that they aren't getting signed up... why? Need a code to sign up.

Now, my suggestion was that clients use a special connection to get a code... this is saved by the client, md5'ed, whatever... and the user uses that code to signup. Sure, they can delete their prefs and sign up again... but the effort in doing that is far greater than what some loser who runs through the website grabbing troll accounts. If anything, this code can be tied to a user login by extending the user data fields in the database, and be required for the client to login... so if the client does nuke the prefs to scope a new code, the existing login won't work anymore... unless they're creative... but I digress.

In anycase, clients could also do signups...

The current method is just not working well enough, and is overly prohibitive.
(Reply) (Thread)
From: bobert225
2002-05-05 08:57 am (UTC)
Do you think a section on WAP (Web Accessible Phone) Clients should be added? Mojo, by camdez, and TapJam, by sol3, are both available. I have tested both of them, and I even referred someone to them in support. They both work great. TapJam can be found at http://www.tapjam.net/lj, and MoJo can be found at http://www.netranked.com/mojo/. Just a thought...

-bobert
(Reply) (Thread)
[User Picture]From: rookin
2002-05-10 12:34 am (UTC)
thanks these are great.
the only problem i found is that the time and date cant be changed. as i live in the UK my post via wap is 5 hrs behind.
(Reply) (Parent) (Thread)
[User Picture]From: phil99
2002-05-05 10:41 am (UTC)

Support for clients

*laughs*

If my client (web based (plug: http://www.philsumner.co.uk/client.html - and yes, I know it's not perfect *smiles*)) ever became popular enough that it got a support request, I'd be astounded ;-)
(Reply) (Thread)
[User Picture]From: stesla
2002-05-05 11:15 am (UTC)
At the point that lj_clive becomes popular enough that somebody I don't already know is using it, I'll be amazed ;) But, I've also got support trackers set up on Sourceforge.

I think it makes sense for clients to have their own journals/communitites. We're developing for LiveJournal, so it would make sense to post any updates on. That way they can get the news about their client on their friends page.
(Reply) (Thread)
[User Picture]From: terwilliger
2002-05-05 12:56 pm (UTC)
A few corrections to the Palm part of the page:

Palm OS™ is the correct way to write it (a space between the two, and it's trade marked).

Also the term "Palm Pilot" shouldn't be used -- the Palm Pilot was an actual device that hasn't been made for *ages*.

Something like:

Palm OS™ (Palm, Handspring Visor, Sony Clié)
(Reply) (Thread)