Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote2013-01-02 05:10 am
azurelunatic) wrote2013-01-02 05:10 am
Entry tags:
Conceptual tests for Dreamwidth design/coding
The master conceptual tests at Dreamwidth are, I believe, the Design Personas.
There are a number of other conceptual tests that long-time Dreamwidth (and LiveJournal) code/design/suggestions participants run against proposed features or implementations. I hope to collect some of them here, and maybe start a wiki page at some point, because this is the sort of stuff that's retained in the tribal knowledge pool, and is therefore vulnerable to the problems of human memory and absence.
* Went to Costa Rica with the Peace Corps (prolonged absence, with or without notice).
How does the proposed feature or implementation affect a user who is away from both their account, and any possible notifications, for prolonged times? In particular, any feature that depends on a user responding to a prompt within say a six-month deadline, with irreversible effects that include data loss, is just not on.![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
christine is the old LJ Support test case: she was previously an active volunteer, and planned her long absence beforehand. She periodically returns and updates us all on her life! She's generally away from her journal a year or two at a time, with no means of access in between.
* Deceased (with or without memorial status) user.
How does it affect (the readers/circle of) a user who will never return? The friends/family of a deceased user may or may not choose to ask for memorial status for that account, so assuming that all accounts belonging to deceased users will have been given memorial status is not a safe assumption.
* Dead Manta Problems
How does it interact with deleted-and-purged accounts, particularly ones who have had the old name reactivated by someone having renamed to it? (Named in honor of the once-and-again deadmantalks, whose old name became ex_deadmanta-some-numbers upon reclaiming the name.)
* Unwanted Contact
How could this be used, either by accident or with malice aforethought, to cause communication between parties who should not communicate with each other? Will it need to restrict anonymous or not-logged-in use or respect ban settings?
* Spam
How could this be used by a spammer?
* Scalability
Consider the potential load if the entire population of the site should use it, or if a large number of users were to use the feature at its highest capacity. For example, what if this feature were used by a high-traffic roleplaying game? (This is usually a developer/architect level problem.)
* Paid Features
Is this a feature that requires a lot of expensive operations? Could this be offset by restricting it (or higher levels of it) to paying users? Would extending a higher level of it to paying users be a nice perk for them? (This is ultimately a staff decision.)
* Malice Aforethought
How could this be used to disrupt others' use of the site? Could any of it be avoided by built-in safeguards or rules, rather than moderation after the fact?
* Journal Types
How does this apply to regular users, communities, and identity users? Does it apply to only one journal type, or can it be usefully used by more?
* Settings Overload
More settings are possibly great for power users, but can cause decision fatigue in neophyte to intermediate users who just want things to work. D has a whole essay on this somewhere, I think.
* Opt-In vs. Opt-Out
Opt-out makes features more discoverable (I think D has an essay on this too), which means that the default state of new features should not piss off, injure (migraine or seizure trigger), or endanger (publish or publicize previously private or covert information such as location or wallet name) users who have not yet turned it off.
I'm sure I'm forgetting some stuff, so if there are other things that either are or should be stuff that gets discussed when talking about a new feature, please feel free to add it in the comments, or in the wiki page once someone builds that.
There are a number of other conceptual tests that long-time Dreamwidth (and LiveJournal) code/design/suggestions participants run against proposed features or implementations. I hope to collect some of them here, and maybe start a wiki page at some point, because this is the sort of stuff that's retained in the tribal knowledge pool, and is therefore vulnerable to the problems of human memory and absence.
* Went to Costa Rica with the Peace Corps (prolonged absence, with or without notice).
How does the proposed feature or implementation affect a user who is away from both their account, and any possible notifications, for prolonged times? In particular, any feature that depends on a user responding to a prompt within say a six-month deadline, with irreversible effects that include data loss, is just not on.
christine is the old LJ Support test case: she was previously an active volunteer, and planned her long absence beforehand. She periodically returns and updates us all on her life! She's generally away from her journal a year or two at a time, with no means of access in between. * Deceased (with or without memorial status) user.
How does it affect (the readers/circle of) a user who will never return? The friends/family of a deceased user may or may not choose to ask for memorial status for that account, so assuming that all accounts belonging to deceased users will have been given memorial status is not a safe assumption.
* Dead Manta Problems
How does it interact with deleted-and-purged accounts, particularly ones who have had the old name reactivated by someone having renamed to it? (Named in honor of the once-and-again deadmantalks, whose old name became ex_deadmanta-some-numbers upon reclaiming the name.)
* Unwanted Contact
How could this be used, either by accident or with malice aforethought, to cause communication between parties who should not communicate with each other? Will it need to restrict anonymous or not-logged-in use or respect ban settings?
* Spam
How could this be used by a spammer?
* Scalability
Consider the potential load if the entire population of the site should use it, or if a large number of users were to use the feature at its highest capacity. For example, what if this feature were used by a high-traffic roleplaying game? (This is usually a developer/architect level problem.)
* Paid Features
Is this a feature that requires a lot of expensive operations? Could this be offset by restricting it (or higher levels of it) to paying users? Would extending a higher level of it to paying users be a nice perk for them? (This is ultimately a staff decision.)
* Malice Aforethought
How could this be used to disrupt others' use of the site? Could any of it be avoided by built-in safeguards or rules, rather than moderation after the fact?
* Journal Types
How does this apply to regular users, communities, and identity users? Does it apply to only one journal type, or can it be usefully used by more?
* Settings Overload
More settings are possibly great for power users, but can cause decision fatigue in neophyte to intermediate users who just want things to work. D has a whole essay on this somewhere, I think.
* Opt-In vs. Opt-Out
Opt-out makes features more discoverable (I think D has an essay on this too), which means that the default state of new features should not piss off, injure (migraine or seizure trigger), or endanger (publish or publicize previously private or covert information such as location or wallet name) users who have not yet turned it off.
I'm sure I'm forgetting some stuff, so if there are other things that either are or should be stuff that gets discussed when talking about a new feature, please feel free to add it in the comments, or in the wiki page once someone builds that.
no subject
Will I, as a user, have to learn all new places for buttons/menus/links? Is this going to alter the sequence of tabbing for keyboard users? Does it shift the "I don't even look/read text, because I know where the button is positioned" clicks from a positive (save changes) to a negative (delete everything in the world MWAHA)?
** How will notifications of changes be made?
THIS IS A RANT, SORRY. One of the things that gave me wrath about LJ many years ago was the yellow-bar of "changes coming" that only appeared on the livejournal.com home page. A page that I visited less than five times in ten years of LJ use. I neeeeeeeever saw that page. I raaaaaarely see the DW home page (and when I do, it's entirely on accident and takes a minute to figure out how I got there). I arrive on the site via a bookmark to my reading list. If, by some reason, I'm on a computer that doesn't have my cookied-login, I either A. hit my journal and log in via the navbar or B. go straight to the login.bml page. If changes are coming to $TheSite, put notice of that change everywhere possible.
I may think of more later, but these are my biggest bugaboos. (Ivy, with hints of Lisa, apparently.)
no subject
They had a yellow bar of "changes coming" on the home page?
I can't remember hearing of this before... and have never seen it, because - like you - I visit the home page extremely rarely, either going straight to my reading page or to the login page. (Whether on LJ or on DW.)
So, +a million for announcing changes not only on the home page.
no subject
After the ruckus about that, LJ started putting the Blue Bar Of Announcements on pages like the flist and such. Still no help for people who block or don't use javascript or whatever ~*~fancy coding~*~ is in place to actually make the bar appear, but a big big improvement over only putting the announcement in one place.
no subject
no subject
no subject
no subject
And tab;enter for post a comment is one of those things that should never be fucked with.
no subject
WORD WORD WORD. It's not a combination I use often - I'm not much for keyboard-only unless I happen to have broken another mouse - but hooooooooooooooooolyhell do not change that behavior.