Yáng Yuǎn Zhì (adudeabides) wrote in suggestions,
Yáng Yuǎn Zhì
adudeabides
suggestions

Expansion and Re-Structure of Contact Information

Title
Expansion and Re-Structure of Contact Information

Short, concise description of the idea
In short, it would be better to separate the contact information from the personal information in Manage/Edit mode, creating a separate, dedicated page for editing this information, then adding a small change in functionality relating to multiple screenames per messaging medium and the ability to display contact information to specified friend/security groups.

Full description of the idea
The full idea includes a few things, so bear with me...

First off, I feel that all contact info on the Manage Personal Info page needs to be removed from that page. Instead of remaining on the editinfo.bml page, a new page (we'll call it editcontacts.bml for this suggestion) will be created which will house this information. Primarily, this is for better organization, but it also allows for better expansion. And, by all contact info, I mean the following:

· E-mail
· AOL IM
· ICQ UIN
· Yahoo! ID
· MSN Username
· Jabber
· Text Messaging (including related sub-options)
· Show your contact information on your LiveJournal (including related sub-options)
· Enable message boards (including related sub-options)
This editcontacts.bml page will minimize confusion and will make the Personal Info page less intimidating (particularly important for the brand-new user) and can be inserted in the manage menu, immediately to the right of Manage->Info.

Secondly, many users have multiple screenames with one messaging service. However, they are limited to displaying one per message medium, forcing them to type out their other screenames in their bio should they wish to have their's displayed. And since many don't know the relevant AIM codes (aim: to start aim, aim:addbuddy?screenname=whatever to add a screename), they either don't format the links (causing extra effort for those trying to contact them), type them incorrectly (resulting in not being able to contact them), or - worse yet - disguise certain malicious AIM code in a seemingly innocuous "AIM Me!" link.

These problems can be reduced, in large part, by allowing members to have more than one screename per messaging medium displayed as the one allowed name per service is currently displayed. On their info/ page, this is simply displayed as additional names, either following each other separated by commas or in list format. On the editcontacts.bml page, however, a little more technical approach should be used. First off, you'll want to limit screenames (say, to 3 screenames per messaging service). Limit or not, however, the page is going to look ugly if you have it displayed as such:
AOL IM __________
AOL IM __________
AOL IM __________
ICQ UIN __________
ICQ UIN __________
ICQ UIN __________
Yahoo! ID __________
Yahoo! ID __________
...and so on, and so on (forgive the crude illustration - I'm typing this in notepad and don't want to get all fancy-graphical...though I can, tonight at home, should it make it easier to understand).

Instead, users should be treated to a drop-down box, listing the different services, followed by a pop-up box (after clicking on an Add button) allowing them to type their screenamename, hit enter, and add a messaging contact to a list that forms directly below the drop-area...
Messaging Services
Add messaging contact: {drop-down}
Select who can see this messaging contact: {another drop-box}
[Add Messaging Contact]

Your displayed contacts:
¬ AOL IM: (screename), viewable by |friends group|
¬ AOL IM: (screename2), viewable by |friends group|
¬ Yahoo! ID: (screename), viewable by |friends group|
I'll get to the "who can see this option" in a second, but this is roughly analogous to, and can be done like - perhaps even displayed as - the editgroups.bml page using JavaScript or possibly DHTML. This also allows for more organized expansion as extra messaging service support is added and integrated for other mediums, and wouldn't require a re-design of the page, but only the addition to the code for the drop-box.

Next, take everything I just said, and apply it to e-mail addresses, too. The ability for multiple e-mail addresses would be appreciated, and would be set-up similarly to what I described for messaging mediums, except for the addition of a "use for" field, allowing the journal maintainer/owner to specify (in a text-box) what to use that specific address for (home, school, work, etc).

Lastly, and probably already guessed by my mentioining it above, I think all contact info - screenames and messaging mediums, text messaging, display of contact info, and perhaps even enabled message boards - should be set-up to where you can display your contact information to selectable friends groups, not just all friends, and allow each point of contact to be displayed to any group we choose (be it all, friends only, priv-todo-add or any other custom friends group). We have this in place for posts, why not apply it to other aspects.

So, say for example, it was decided to adopt my idea...after the change, I'd have 2 e-mail addresses, and 2 AIM screenames listed...one of each publicly listed for strangers, and the other of each being visible only to a hypothetical friends-group called "inner circle".

I hope that all made sense. I contemplated posting them as separate ideas, but the ideas all build on each other, really. And for those who might say this should/could be limited to paid-status users, I say foo on you - this should be something ALL users be allowed, as it's likely to promote more interaction on LJ...it's all about communication.

An ordered list of benefits

  • Less intimidating for the new user
  • More logically organized and less confusing
  • Allows for better, more organized expansion in the future
  • Allows multiple points of contact to be displayed
  • Allows user to better specify who each point of contact is viewable to
  • Allows for friends groups to be used in a more versatile manner
  • Allows for more fields to be added to editinfo.bml, since it'd be less crowded
  • No real changes to the front-end of the user info page, which is nice
  • May encourage use of LJ as a communications, not just journaling, tool.
  • Allows me to brag that it was my idea when people like it, and someone to blame in the unlikely event others not like it ;)
  • An ordered list of problems/issues involved

  • A number of changes in coding
  • Some changes in design and structure
  • FAQs would have to be written and some revised
  • People might not know about it initially, though a significant change like this should be mentioned in news
  • May minorly increase load, but good geek coding will prevent that
  • May take time to implement
  • An organized list, or a few short paragraphs detailing suggestions for implementation

  • Get the code guys cracking (since they know better than I how to do this) and stay on them, ensuring a steady supply of Coke and M&Ms to minimize delays
  • Drop a note in lj_userdoc letting them know of the changes so they can update accordingly
  • Announce in news once completed
  • Enjoy
  • Tags: ~ historical
    Subscribe
    • Post a new comment

      Error

      Anonymous comments are disabled in this journal

      default userpic

      Your reply will be screened

      Your IP address will be recorded 

    • 36 comments