Log in

No account? Create an account
Envisioning the Downloads Page of the Future - LiveJournal Client Discussions — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Client Discussions

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

Envisioning the Downloads Page of the Future [Jun. 24th, 2002|09:54 pm]
LiveJournal Client Discussions

The Downloads page, where everyone goes for his or her client needs, has remained in its current form for far too long. Back in October 2001, evan rewrote the Downloads page in a mesh of Perl, HTML, and BML; before that it had been a simple HTML file along with a little BML. Since then, there have only been minor updates to the page, mainly to add new clients and platforms. As I'm sure all of you have noticed, the page certainly could be better than it is now, given the growth of LiveJournal and the flood of new clients that have arisen.

Why should you care about the Downloads page? Well, if you are a client author, you want users to be able to find your program with ease. The easier it is for a user to find a given client, the more users will choose to use a client (preferably yours, of course) over the Web interface. If you are one of the precious few who administer the site, getting people to use clients is important--it translates to fewer hits to the Web and image servers, and, depending on the client, keeps people from obsessively reloading their friends page for lack of anything better to do.

As the first comment in the download/index.bml file says, the structure is perfect for a database. Optimally, the page would be recoded in such a manner. However, due to the fact that developers are few and far between--and those that do contribute actively are quite busy--we're stuck with my skills (and anyone else who wishes to help) for now.

On that note, I have been thinking about how the Downloads page should look and work in the future.

Major Issues
  1. Listing of client features

    Problem: If you're anything like me, you probably find the text descriptions for the clients nearly useless. All of them essentially say, "This client is for LiveJournal," occasionally listing the features of the program in question. There needs to be a standardization of this. The best way to go about this also happens to make it far easier to strip the English out of the page for internationalization (see Major #2).

    Solution: A set of flags for each client which indicate its features, to be displayed in a table where the text description formerly appeared. A small bullet or checkmark icon should appear to the left of each element.
    Here's how it would work. "Features" would replace "Description," with a variable to state "(as of version %n)" to allow for laziness on the part of the download page maintainer. After this, there would be short flags to list the features (which would subsequently be automatically formatted into the table by the Perl code at the bottom). The features that clients have displayed up to now include the following:

    • Online posting / Offline posting / Online and Offline posting
    • WYSIWYG (What You See Is What You Get) mode / Preview mode
    • Access and edit past entries
    • Download entire journal
    • Custom security support
    • Default security level support
    • Spell-checker
    • Link assistance (e.g., easy creation of <lj user="welovebrad">)

    • Select user picture
    • Select current mood/current music
    • Match userpics to mood
    • Music auto-detect (and the players supported)

    • Friends page update notification
    • Friends and friends groups editing
    • LiveJournal Console interface
    • Multi-user support
    • Locally encrypted passwords
    • Support for other LiveJournal-based sites

    • Available in languages: En, De, Jp, etc...

    As the clients these days have become quite well rounded, a few of these can be eliminated eventually (Select user picture, etc). I would be hesitant to add any new clients that didn't have such features to the Downloads page in the future. But that's a post for another day.

    Implementation: This requires a fair number of modifications to the Perl code on the page, along with the HTML (would CSS be better?) to draw the tables and icon. I'm capable of doing the latter in simple HTML, and given time (a month or two) I can accomplish the former. However, it would be nice to have someone code this for me, particularly the Perl. It would also be nice if I had a diamond tiara, but that ain't happening.

  2. Internationalization

    Problem: The Downloads page is ancient compared to other pages on LiveJournal, as it still has English hard-coded on the page. While not as vital as other sections of the site, it's still important to port this so that the Translation Squad™ can attack this with their Internationalizing Touch.

    Solution: This would be a pain in the posterior with the current text descriptions, because they really don't say anything (see #1). Therefore, a clean stripping of the English from the page requires that the above be completed beforehand. The client descriptors that I mentioned are easy to translate, and it plays nicer that way.

    Implementation: Easier than riding a bicycle blindfolded whilst juggling plums in both hands. Shouldn't be too hard.

Minor Issues
  1. The double-counting issue

    Problem: If you look at the present Downloads page with all of the clients displayed, you will note that PocketLJ is listed twice, due to the fact that it works on both Palm OS and Windows CE devices. This is a minor annoyance currently, but it becomes a large problem as more and more clients become multiplatform. An experimental layout that I am toying with would wither and die if this bug isn't fixed beforehand.

    Solution: Either find someone proficient in Perl enough to fix this, or remove the "View All Clients" link and the accompanying code. I'm tempted to lean towards the latter given that my time is limited. Also, seeing all clients without their accompanying platform can be confusing for some users. Would anyone miss this feature?

    Implementation: Click, drag, delete (or, code, code, code).

  2. Demi-clients

    Problem: More programs that do not post to LiveJournal but interact with it in different ways have started to pop up. There is a valid question as to whether these belong on the Downloads page and not on a sub-page of sorts.

    Solution: The client feature standardization (see Major #1) partially solves this problem. Some demi-clients have only the download journal feature, and others only have friends page update notification, and the flag implementation covers these. Others, however, are still not covered--namely, the Mac Sherlock plug-in which searches for users with a certain interest. Of course, it wouldn't be hard to just add a flag for that, too--but if more clients appear in the shadow of the Sherlock client, we're in trouble. In such a case, a demi-client page can be created.

    Implementation: None, unless a page needs to be built.

That's it. For those of you who have read through this entire post, thank you. Because most people don't read such long posts, I will be making a short post right after this one asking what people think the Downloads page should look like in the future. Hopefully I won't have all of the non-readers all agreeing on something that is the complete opposite what I have laid out above.

Comments, questions, and critique are welcome.


[User Picture]From: rahaeli
2002-06-24 07:05 pm (UTC)
I like this idea very much. I know that when I go looking for a client for a new platform, i would very much like to be able to see the list of features in ONE place rather than having to go looking in eight billion.

One thing that would make our lives easier in support would be a prominent link to the client communities/client author's contact informatoin, too.
(Reply) (Thread)
From: evan
2002-06-24 07:20 pm (UTC)
Look at suggestions if you'd like to make suggestions for LiveJournal.

... heh. I mean, a patch is a better idea. And updating the download page is laborious enough as it is...

Though I suppose planning it all out is important so the db schema doesn't change.
(Reply) (Thread)
[User Picture]From: xb95
2002-06-24 08:19 pm (UTC)
I like your ideas. I think this is a very worthy project, and I'd be more than happy to help with the Perl/SQL/DB portion of it. Catch me on IRC sometime and we can chat about this and see what we can come up with. (I'm also really big on getting more publicity for my client, so heh. ;))
(Reply) (Thread)
From: scientaestubiqu
2002-06-24 09:03 pm (UTC)
I've love to see it in a filtered format, like the support board

Show only Mac clients

Show only Palm clients

Show only clients with x feature
(Reply) (Thread)
[User Picture]From: thelovebug
2002-06-25 05:35 am (UTC)
Ok, since you mentioned PocketLJ, I'm kinda compelled to reply! ;-D

with regard to the double entry of PocketLJ, rather than listing the client twice - once in PocketPC and once in Palm - wouldn't it make more sense to list the client once, and link two Platforms to it. i.e. the opposite to the way it is at the moment. PocketLJ, as an example, will be expanding its platform-base in the near future, so this would be very useful.

Your idea of flags identifying which features a client has is great! Searching of these features (and platforms) would follow nicely.

What about maintenance of the client details? I'm thinking that all client developers should be able to maintain their own clients features for the download screen. Some clients are being constantly developed, so new features could be introduced on a regular basis. Giving control of the content to the client developer would make it far easier on them to get the details updated. However, this could open up abuse of the system. So, give "trusted" (or whatever the word is) developers a priv so that any changes they make are applied immediately. Those that don't have that priv get their submissions put into a queue that specific people (download-admins?) can make live.

I hope this makes sense! :-)
(Reply) (Thread)
[User Picture]From: benzado
2002-06-25 02:28 pm (UTC)
Clients already identify themselves with a version string that, as far as I know, is only used by the stats page. Perhaps the new downloads page could make use of the table of known clients.

I'm not suggesting listing every client that has connected (there would be a lot of junk from test clients, etc.) but maybe some interesting connections could be made.

For instance, in the Profile view the list of clients used could become links to the client's info on the download page.
(Reply) (Thread)
[User Picture]From: mart
2002-06-26 07:21 am (UTC)

I'm definitely in favour of putting this in the database. Lots of client developers have been waiting a long time to be able to admin their own entry in the client section, and this would be ideal for that combined with a 'clientadmin' priv which accepts the first part of the clientversion string as a key, which would also used to index the clients on the download page.

Eventually, this same mechanism could be used to provide client authors with the ability to send messages to their users in a similar way to how the old Win32-MFC clients get messages now.

This requires quite a few database tables, though, to allow for clients having multiple features (which could work a lot like the prop lists LJ already has), being on multiple platforms (again, similar to prop lists) and multiple versions available for download each with their own description. Eventually it'd presumably need another to list the messages sent to different versions of a given client. I'd make sure you've got the DB schema straight before doing anything else, as it's going to be a pain to rehash it later.

(Reply) (Thread)