xenofalcon (xenofalcon) wrote in lj_clients,
xenofalcon
xenofalcon
lj_clients

Envisioning the Downloads Page of the Future

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.

Subscribe
  • Post a new comment

    Error

    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments