CAPS LIKE WHOA (jc) wrote in suggestions,
CAPS LIKE WHOA
jc
suggestions

Various improvements to the Invite pages

Title
Various improvements to the Invite pages

Short, concise description of the idea
A collection of ideas to neaten up the Invite pages, including a system to transfer invite codes to another user

Full description of the idea
I feel sorry for the people in the top 100 on support's high scores page. (I realise I'm including myself in this statement, so try and ignore that for now.) Not for the sheer amount of time they've put into support to get there, for which they should be applauded; but for how the Invite pages must take a hell of a long time to load as a result. This is because as it stands, the main page is one long list of all the invite codes you have, and even the generate codes page lists a reason for each and every invite code generated in the past. For the sake of server load, page load times and sanity, these two pages should be neatened. Here's a list of things that could go a long way towards this goal.

  • Split generated codes into two groups, used and unused, and separate each group into groups of 25 for display purposes;
  • Attach the reason a code was generated (and perhaps a timestamp) to each invite code on the main page, and in turn limit the number of "prior" reasons displayed on gen.bml to fifty;
  • Implement a transfer mechanism, whereby user A can transfer up to five invite codes at a time to user B. This would involve marking that number of user A's codes as "used/transferred to <lj user="B">", and generating new codes for user B.

An ordered list of benefits

  • Cleaner layout and easier access to invite codes;
  • Reduced server load and page load times;
  • Certain invite codes would have more sentimental value than others ("oh look, this user got to use the invite code I earned when I reached my goal of 20 support points. Ain't that special?");
  • Transfer mechanism would save code sharers the trouble of remembering who was given which codes;
  • Transfer mechanism hands over (partial) responsibility of used invite codes from sharer to receiver, as sharer would not know who had the use of a transferred invite code via the receiver.
  • An ordered list of problems/issues involved

  • Interface clean-up benefits only a small number of users;
  • Certain invite codes would have more sentimental value than others ("the invite code I earned when I reached my goal of 20 support points is sacred, nobody's getting to use it, grr!");
  • Required timestamp/reason metainfo is probably not already attached to a particular invite code in the database;
  • Transfer mechanism could be abused in the form of code sharing communities gaining access to a large number of "donated" codes;
  • Transfer mechanism might have to take into account which codes user A wants to transfer (see sentimentality value, above);
  • Invite codes are going away Any Day Now™.
  • An organized list, or a few short paragraphs detailing suggestions for implementation

  • Implement the changes to /invite/ and /invite/gen.bml, using attached invite code metainfo (if it's available) on the main page;
  • Implement transfer mechanism, which shouldn't be too much of a headache;
  • Or, forget about this suggestion, because invite codes are going away Any Day Now™.
  • Tags: § obsolete
    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 

    • 14 comments