marahmarie: my initials (MM) (Default)
[personal profile] marahmarie

Title:
Make links in Private Messages clickable.

Area:
Private messaging system

Summary:
Upon sending a private message to a Dreamwidth user the other night I looked upon the link I included in said message and realized it was unclickable. I thought to myself, what if mobility or other issues kept me from cutting and pasting the link into the browser; what if I were a user who simply needs to be able to click on that link with no other action required? So I'm proposing making all links clickable in private messages.

Description:
Upon reviewing a private message I sent to a Dreamwidth user the other night and realizing the link I included in it was unclickable, I began wondering why links in private messages are unclickable and how much trouble it might be to make them clickable in the future. Currently any links you include in Private Messages are shown in plain text with no way to click through on them to the linked content. I figure this is an accessibility issue for anyone with health issues that prevents them from using the mouse or keyboard fully or who simply experiences pain and over-exertion of already strained joints and tendons upon not being able to click on any links presented to them. So I'm proposing making all links clickable in private messages.


Making links clickable in PMs benefits all users by adding ease of use, speed and simplicity to the PM system; the only downside is that a straight clickthrough could lead a user to say, a malware-infested website. Spammers who sign up for Dreamwidth accounts and then use the PM system simply to spam, and existing users who turn against each other in nefarious ways could use the straight clickthrough function to make it easier for a user to visit a website full of spam and/or malware. But the capability for that sort of abuse is there now; the only difference is it takes a user two more steps (cut, paste, then press enter on your browser's address bar) to get to the website in question. Forcing a user to look at the link by disabling it and requiring extra steps to make it work might be a good idea from a security stand point but it comes at the cost of accessibility and ease of use for all Dreamwidth users.

Poll #12196 Make links in Private Messages clickable.
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
33 (54.1%)

Should be implemented with changes. (please comment)
14 (23.0%)

Shouldn't be implemented.
6 (9.8%)

(I have no opinion)
7 (11.5%)

(Other: please comment)
1 (1.6%)

sparklycockles: (Default)
[personal profile] sparklycockles

Title:
Popular Communities (implementing something similar to Livejournal's feature?)

Area:
Classification

Summary:
Livejournal has a feature called "Popular Communities" that sorts communities based on usage/popularity that I would love to see replicated for Dreamwidth.

Description:
On Livejournal there is a list of communities sorted from the most popular to the least. At the top of the list you can search for what community you're looking for and jump straight to it. There are other more complicated features relating to it (such as the social capital now displayed) but I don't really think they're necessary.

I think this feature, or something similar, could be useful for people searching to add new communities to their friends-lists or for looking up the activity in a community they are considering joining. It's a bit of an "extra" though - the site doesn't really require such a change.

But honestly I just really want to see where my own communities would rank! Mark did something similar to this on his own journal (informally, of course) and my community was #17 (or thereabouts). I'd like to know if it has increased or decreased since that time! (Another informal list would also be interesting!)

Poll #11552 Popular Communities (implementing something similar to Livejournal's feature?)
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
8 (14.3%)

Should be implemented with changes. (please comment)
5 (8.9%)

Shouldn't be implemented.
19 (33.9%)

(I have no opinion)
24 (42.9%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Integrate better with LiveJournal's "spoiler" tag

Area:
entries, comments, importing, crossposting

Summary:
LiveJournal has implemented a <lj-spoiler> tag, which should be accounted for when importing and crossposting.

Description:
There's been past discussion (most recently http://dw-suggestions.dreamwidth.org/1303478.html ) about how to best make a spoiler/trigger/not-expanded-by-default tag work for entries and comments on Dreamwidth. LiveJournal has since implemented a method to do just this, and it would be wise to remain compatible with it.

When importing, entries with <lj-spoiler> tags should retain the type of concealment it is, the custom warning text if any, and the text within.

When importing, comments with <lj-spoiler> tags should not lose any data.

When Dreamwidth implements its own version, things tagged with <lj-spoiler> should be backwards compatible - if already posted, they should be treated accordingly.

New crossposted entries containing the <lj-spoiler> tag should be passed on to LiveJournal without mangling the tag; when our version happens, it should convert to LiveJournal syntax when crossposting to LiveJournal, just as usernames are.

New entries containing the <lj-spoiler> tag should be displayed sensibly on Dreamwidth, either consistent with a regular <cut> tag (if that's quick and easy to set up before implementing it properly) or properly.

Whatever method we use should remain accessible. If implemented with scripts for inline expansion, non-script viewing should retain any custom warning text and the fact that this was concealed, and give sufficient time and space for people to decide to stop reading (this should accommodate very fast readers who skim and can absorb the gist of whole sentences/paragraphs in seconds before their executive function has caught up, as well as screen reader users who may need time to tell their screen reader to stop reading). It should also not suck for mobile device/small screen users.

One possible method would be to automatically add "spoiler space" as was done manually on email lists of old: for example, typing <mask text="OMG!">WTF!!</mask> (or however it's decided to do locally) might result in:

*** MASKED CONTENT: OMG! ***

*
*
*
*
*

WTF!!

*
*
*
*
*

*** END MASK ***

Poll #9954 Integrate better with LiveJournal's "spoiler" tag
Open to: Registered Users, detailed results viewable to: All, participants: 73


This suggestion:

View Answers

Should be implemented as-is.
52 (71.2%)

Should be implemented with changes. (please comment)
4 (5.5%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (21.9%)

(Other: please comment)
1 (1.4%)

aresvallis: (Default)
[personal profile] aresvallis

Title:
Icon keywords

Area:
Icons

Summary:
The icon keywords are an old and outdated system, it'd be easier for users if a better management system was put in place, especially for high numbers of icons.

Description:
Icon keywords really need to be updated. It is difficult and cumbersome managing keywords for icons especially when having a high number of icons. The current system has literally not changed much since 2001. It would be nice having a sort of keyword managing place, one where you could assign icons (and drag and drop would be awesome there!) or rename or merge keywords as you can for entry tags. Additionally, keeping a list of keywords that you've used but don't currently have an icon assigned would be helpful and useful to roleplayers. Even if it's just a static list would let the user see what they've used. As denise said here:
http://dw-biz.dreamwidth.org/7186.html?thread=773394#cmt773394
it might be computationally expensive getting a retroactive list from old comments, I'd suggest not doing that though and just adding a old keyword if someone actively views a comment with an old keyword- it would be looking for that icon anyway and it'd just display the default when it doesn't find it, though I'm not familiar with how the process works exactly.

Poll #9952 Icon keywords
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
12 (22.6%)

Should be implemented with changes. (please comment)
9 (17.0%)

Shouldn't be implemented.
8 (15.1%)

(I have no opinion)
23 (43.4%)

(Other: please comment)
1 (1.9%)



Edit!!!! In order to clarify + additional:

It is extremely awkward managing keywords from the icon page from a little tiny text area box, particularly when having many large sets of keywords on one icon with only commas as a separator. I suggest a separate manage area for a list of icon keywords currently in use, and possibly a list of keywords used in the past for reference and the ability to reassign old keywords to new icons. People do not always remember exactly the way they typed a keyword they don't actually have saved.

We have a management page for entry tags, where we can delete, rename, merge and view what is tagged to a specific entry tag. I am suggesting something similar for keywords- if not their own page, at least a section on the icon upload page where we do not have to deal with the tiny text area and only the text area. I can see being able to select a keyword with a check box and hitting a "Rename" button to be able to rename keywords, or select two keywords via check box and hit a "merge" button, or select some "delete" button. Then possibly an "add new keyword" button. That would make keywords more manageable and I don't think it'd require a lot of work, and we already have a check-and-hit-button to delete icons themselves.

We can only rename keywords, we cannot merge them. I've tried to merge keywords, and it didn't work. There is no obvious option nor way to merge keywords. Trying to rename one into another fails. -This is on Bugzilla and is already on the to-do list, but it's part of the bigger management system, so I thought I should include it.

Renaming keywords is sort of a hit or miss using the text area on the icon page, especially if there are multiple keywords to an icon. You do not know if the rename was successful until you go to check comments made with the old keyword- there is absolutely no confirmation, and it is far too easy to typo and create a horrible Frankenkeyword out of the one you're trying to rename and one of the others. Then it becomes annoying trying to undo that because there is no undo button, either, and you have to figure out what keyword you renamed, fix the innocent keyword, and try to rename the suspect keyword again.

This is the same old tired system that has been in use since LiveJournal's early days: By that, I am implying: surely with new coding and technology we should be able to have a more dynamic, easy to use icon and keyword management option.
[personal profile] imaginemeandyuu

Title:
Thread Logging (or "Dreamwidth Journal History")

Area:
Threads / notifications

Summary:
It can be hard to track down all the posts you've made or threads you've started or replied to -- even with tags, commenting in your journal, other people's journals, communities, etc, can make it hard to have any kind of record of your own experiences on the site. If the site can record every one of your posts/top level comments (or the top-level comment you replied to) and report it (somewhere on your console, or into a specific entry in your journal) it will be much easier for people to reread their old posts/threads and track their life on DW.

Description:
Right now it's difficult to find everywhere you've posted or commented to and thus track your 'life' on this site. Basically, if someone wishes to do "thread logging", it all needs to be done manually -- you can track threads which sort of does it a little, but that again is a manual task. There's no automatic record, no recorded history, of where you've commented and what you've said.

Especially as the roleplay community gets larger this is something I feel will be more in demand (as rpers frequently like to reread the character development they go through, but sometimes this can be months or years of posts to wade through -- with an RP like CFUD, you've got six years of roleplay! Or, even if they're not fans of rereading, a lot of sites request you turn in your activity every month, which involves wading back through posts trying to find it, using tags liberally to help yourself keep track (but again, tags are added manually, which means human error). Thread-logging is standard but usually involves manual work.

Perhaps there can be an option on the site which outputs (into a console box or an entry that you set up and somehow mark as a "history" entry) the links for your comments/posts. Obviously doing every comment would be frustrating, so I'm thinking:
A) Any post you make, the post link would go in here.
B) If you make a comment, the History console identifies the top level comment in that thread (whether you started the thread or replied to it) and links it, discarding anything after. (Obviously in the case of B it would also check if it has already linked this thread and not link again if so).

Additional thoughts, details, and concerns:

- It would need to be arranged by date somehow, whether just a chronological order (top-down) or with datestamps of the toplevel comment beside them.

- Since what's just a list of links could become unwieldy fast it would be good for the user to either be able to convert into linktext instead of a plain URL, or at least have a field where the user could add a comment beside the link to identify the content if they choose to (ex: (LINK) - "Umeda and Akiha have a picnic. Mood crab sings them a song.")

- Having a list of the number of your total comments in the thread/post would probably be super useful to RPers (obviously this would mean that either it would have to dynamically update with each reply like the comment section in your profile OR the user could manually run to check for all updates you've made with that username).

- If this WAS going to be planned anyway, obviously the fact that people imported journals would make it difficult to have a 'full' list of their journal's history, unless there were a way to run the function to comb back through all appearances of the relevant username on DW (using their ID) and do a link dump. (This would be ideal for me, as a CFUDer who really wants to reread old threads). Since DW has such a strong search function I think this would theoretically be possible using something similar to the search functionality using the journalname ID, but I'm no programmer.

- Privacy issues -- if in a console you need to be logged into to see this isn't a concern, but if not, whatever journal entry this output into might need to be private by default (with the user able to make it public if they chose to?) in case you didn't want the whole world to see what that journal had been up to.

- This obviously wouldn't track anonymous comments, so if users can manually add extra threads (as in an editable entry) for any 'anon posts' they participate in, or if they did a 'bodyswap' with journals or so on, they could help keep track of these extra things as well. Not totally necessary as long as the journal name's history is added but it'd be a nice bonus for completion's sake.

- If this is impossible to do on the site itself, are there any programmers on the suggestions team or reading this otherwise who may be able to draw up an associated client that could run a similar function of outputting posts/the top comment of threads with a journal name? It's currently difficult to get full thread logs without having to manually keep track of things yourself, which is doubly difficult if you have multiple computers you thread from, if your game doesn't use tags, etc.

Poll #9801 Thread Logging (or "Dreamwidth Journal History")
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
11 (19.3%)

Should be implemented with changes. (please comment)
5 (8.8%)

Shouldn't be implemented.
18 (31.6%)

(I have no opinion)
21 (36.8%)

(Other: please comment)
2 (3.5%)

starsandauras: (Default)
[personal profile] starsandauras

Title:
Adding Jersey, Guernsey, and Isle of Man to profile

Area:
profile

Summary:
Adding the Crown Dependencies of the Channel Islands (Jersey and Guernsey) and Isle of Man to the location drop down on the profile.

Description:
I'm sure that users from these places can easily select the UK as their location, but I suspect that they might like the option of their specific island as well. If nothing else, I doubt having the option would be detrimental.

Poll #9055 Adding Jersey, Guernsey, and Isle of Man to profile
Open to: Registered Users, detailed results viewable to: All, participants: 75


This suggestion:

View Answers

Should be implemented as-is.
53 (70.7%)

Should be implemented with changes. (please comment)
2 (2.7%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (26.7%)

(Other: please comment)
0 (0.0%)

magibrain: A radiation symbol. It appears to be a little bit on fire. (Default)
[personal profile] magibrain

Title:
Spoiler DW-tag

Area:
DW custom tags

Summary:
Add a tag to easily add spoilertext to a post.

Description:
I suggest a [spoiler][/spoiler] tag which would automatically generate spoilertext (often black text on a black background, so that a user can choose to highlight it to read it), with a hidden-from-screen-display but screen-reader-accessible (possibly using WebAIM's hidden content trick - http://webaim.org/techniques/css/invisiblecontent/ ) link to skip the spoilered content. The rough format I've been using in my posts is this (brackets flattened because preview didn't like &lt; and &gt; codes):

[a href="#skip_spoiler_1" style="width:1px; height:1px; position:absolute; left:-10000px;"]skip spoiler[/a][span style="color:#000; background-color:#000;"]SPOILERS SPOILERS SPOILERS[/blockquote][a name="skip_spoiler_1" /]

It seems that the following code:

[spoiler]SPOILERS SPOILERS SPOILERS[/spoiler]

would be much cleaner, and guarantee accessibility for people using spoilertext who might not otherwise consider screenreaders.

As for drawbacks... I'm not sure how many people actually use spoilertext on a regular basis, I don't know if color choice would be controversial, I'm not entirely happy with the disparallel between functionality for sighted and screenreader-using folk (where people reading visually have to take action to see the spoilered content, but people using a screenreader have to take action to *avoid* being spoilered), the outputted HTML is still a little bloated, the trick to not display the skip link is a kludge (because screenreaders have erratic handling of both visibility:hidden and display:none), and I imagine it would get extremely ugly if used on a large patch of text. But it'd be cool to hear discussion on any/all points. :)

Poll #9002 Spoiler DW-tag
Open to: Registered Users, detailed results viewable to: All, participants: 90


This suggestion:

View Answers

Should be implemented as-is.
36 (40.0%)

Should be implemented with changes. (please comment)
21 (23.3%)

Shouldn't be implemented.
10 (11.1%)

(I have no opinion)
22 (24.4%)

(Other: please comment)
1 (1.1%)

fiddlingfrog: (Default)
[personal profile] fiddlingfrog

Title:
Send inbox notification to new OpenID accounts upon comment or entry importation

Area:
inbox, importer

Summary:
When the importer imports a comment, it should leave a notification in the inbox of the associated OpenID account stating "A comment you left at {original site} has been imported to {Dreamwidth journal/community name}."
When the importer imports an entry from a community import, it should leave a notification in the inbox of the associated OpenID account stating "An entry you wrote in {original community} has been imported to {Dreamwidth community name}.

Description:
Currently OpenID accounts have very little ability to find comments, and soon entries, that have been imported to Dreamwidth. The Recent Comments page only goes back 10 comments, and deleting one of those comments doesn't let another one slide in at the back of the list. Currently the search by poster function [http://foo.dreamwidth.org/?poster=] doesn't work for OpenID accounts, not by using the displayed name {bar.livejournal.com} nor by using the internal name {ext_###}. Unfortunately, it's too database heavy to try and search for all comments and entries an account made anywhere that isn't their journal, so my idea is to give the user a place to start looking themselves.

When the importer imports a journal or community, it should leave a notice in the Dreamwidth inbox of the OpenID account that's been created (or added to) stating what action just happened. It only needs to leave one notification per import.

Under this idea, a user from LiveJournal would log into Dreamwidth for the first time using their OpenID credentials and find an inbox with several notices already waiting for them, like this:

"Comment imported to {Journal A}"
- A comment you left in {Imported journal's original address} has been imported to {Journal A}
"Entry imported to {Community B}"
"Comment imported to {Community B}"
"Comment imported to {Journal C}"

Edit: It's one message per import, not one message per comment/entry.  If you count the community and comment import as a single job, it's up to two message per import.
For example, say somebody decides to import [livejournal.com profile] gardening to DW. In my OpenID account's inbox I'd get one notification saying that an entry or entries I posted there had been imported to DW. I'd get another notification saying that comments I had left there had been imported to DW. And that's it.

Upsides: OpenID users feel more in control of imported content.
Downsides: Will probably slow down the importer.

Poll #9001 Send inbox notification to new OpenID accounts upon comment or entry importation
Open to: Registered Users, detailed results viewable to: All, participants: 59


This suggestion:

View Answers

Should be implemented as-is.
18 (30.5%)

Should be implemented with changes. (please comment)
11 (18.6%)

Shouldn't be implemented.
5 (8.5%)

(I have no opinion)
25 (42.4%)

(Other: please comment)
0 (0.0%)

facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
[personal profile] facetofcathy

Title:
Compact Comment View

Area:
Comments

Summary:
An even more compact view than the current top-level comments view, this version omits the comment text and the icon giving the reader a short list of the top level comments on a page.

Description:
Inspired by the Comment Indexing suggestion and green_knight's comment there, and by the new fully collapsed comment view on Livejournal.

Offer a comment view that shows top-level comments in a compact form.

Purpose:

The Compact Comments View would give readers a stripped-down view of all the top-level comments. This view omits the comment content and acts as an index for the page.

It provides a shorter list than the top-level comments view readers can quickly scan to find the comment they are looking for. This view shows who commented, the topic of a comment and how active the conversation is by including the number of replies.


The reader would see:

* the date and time
* the user name
* the subject line
* the number of replies
* an expand link

Not shown:

* the user icon
* the comment contents
* the track, reply, thread, parent or edit links

Format:

* Ideally, this information should take up one or two lines of text on the reader's screen for each comment

* The expand link should expand the top-level comment, revealing its content.

* Clicking the subject line should open the thread headed by that comment.

* The number of replies link should expand all the replies and the top-level comment, leaving the rest of the comments in compact view.


Of particular value to:

* Communities where subject lines are usually used--anon memes, prompt fests or kink memes, discussion communities
* Posts where top-level comments might be very long and readers want to read only some of them--comment fic fests, very active or structured discussion posts
* Readers who want to find comments by specific people, or only active discussions
* Readers with slow connections who want a faster browsing experience
* Readers with smaller screens or who use very large text

Poll #8900 Compact Comment View
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

Should be implemented as-is.
18 (30.0%)

Should be implemented with changes. (please comment)
4 (6.7%)

Shouldn't be implemented.
4 (6.7%)

(I have no opinion)
30 (50.0%)

(Other: please comment)
4 (6.7%)

archangelbeth: An anthropomorphic feline face, with feathered wing ears, and glasses, in shades of gray. (Default)
[personal profile] archangelbeth

Title:
Separate Customized Posting Page for Mobile Devices

Area:
Posting To Dreamwidth

Summary:
Make it possible to have a customized posting page that recognizes when one is on a mobile device (or can be reached quickly, at least).

Description:
I just turned on the beta version of the new posting page and it. is. awesome. I can't <I>quite</I> duplicate the set-up that I'm accustomed to or the Ultra Perfect For Beth version (I'd like to have icon-choice up at the top <I>and</I> the bottom...), but overall? Love it.

On the other hand, the way I've put the boxes probably isn't going to agree with my phone. In the absence of a full-featured Mobile Dreamwidth app (to save drafts, yadda), how about a .mobile. posting page, where we can move the boxes around, and open and close them, to suit our <I>phone</I>-posting habits? We could have a smaller number of boxes open than our usual default, for instance, and arrange them all in a column, and presto! Much more phone-phriendly, er, friendly than, say, boxes surrounding the text-entry box!

Drawbacks: having to save two custom pages per user. Having to either recognize mobile devices (and have a way to go to the non-mobile site when people don't want their device recognized; an iPad could probably use the default posting page, while an iPhone would cry), or add a "jump to mobile posting page" somewhere. Gives users More Things To Think About.

Benefits: Makes posting from a phone or tablet easier, even without an App For That{TM}! Showcases the flexibility of the Almost <I>Perfectly</I> Awesome posting page!

Poll #8879 Separate Customized Posting Page for Mobile Devices
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
18 (32.1%)

Should be implemented with changes. (please comment)
5 (8.9%)

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
32 (57.1%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Streamline logged-out viewing of NSFW/18+ content

Area:
logged-out users, entries

Summary:
Allow logged-out users with no content preferences set to declare their preferences in some fashion to reduce the number of steps they have to take in order to view flagged content. This would be especially helpful for people who use bookmarking services and offline cached content services.

Description:
There should be some way for logged-out users and people without accounts (and external services, which generally do not have accounts) to view content flagged as NSFW or 18+ with a minimum of barriers, provided that there is some acknowledgment.

Some services have a way to add something like "?view_adult=true" to the end of a link.

One could possibly also do this with saved cookies, but that could be an issue for external services attempting to index the site. On the one hand, sometimes it's good to have a thing that's technically public but the contents have not been crawled. On the other hand, "NSFW" shouldn't mean "dear search engines, please don't index or cache this", it should mean "NSFW". (I am not opposed to the idea of an entry-by-entry no-index/no-cache sort of setting, but I don't want it in my NSFW/18+.)

An external service could always set up an account for their indexing tool to use, but that's a one-by-one sort of solution, and not all external services would necessarily be willing to do that, and it doesn't seem elegant.

Having a URL argument could lead to someone posting a link somewhere and someone else clicking it and getting a faceful of something they did not want. On the other hand, there's nothing stopping the entry owner from posting something blatantly NSFW with no entry settings to indicate that it is. The regular site view does display a discreet little warning at the top of every flagged entry, so even a link where a warning splash page was bypassed would have some indication that this was NSFW/18+. It could also lead to someone who is under 18 logging out and using the URL argument, but a logged-out user can view an 18+ flagged entry by clicking the button that declares them 18+.

If consensus is that the existing NSFW/18+ warning is too subtle for being useful to visual logged-out users who have bypassed the warning splash page, one compromise might be to make a larger header area with a more prominent warning when that page has been bypassed, to (depending on screen size) attempt to force the actual NSFW content down below the fold, in the fashion of spoiler space, and to have a notice that is less easy to ignore than a 16x16 icon. (Text-only users could get the same effect; I'm not sure of the best way to get the same effect for screen reader users.) (However, having a very large bright red scary type of visual warning could be bad for misclicks-at-work use case; it should advise the user that they should be aware without alerting the whole office that they just clicked into something NSFW.)


This suggestion is apropos of the Pinboard most-wanted-features discussion, which includes thoughts on handling Dreamwidth NSFW/18+ flagged entries.

Poll #8404 Streamline logged-out viewing of NSFW/18+ content
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
18 (41.9%)

Should be implemented with changes. (please comment)
6 (14.0%)

Shouldn't be implemented.
7 (16.3%)

(I have no opinion)
8 (18.6%)

(Other: please comment)
4 (9.3%)

[personal profile] alexbayleaf

Title:
Rearrange the logged-in homepage

Area:
homepage

Summary:
Make the logged-in homepage more appealing by modernising the UI, showing more relevant and dynamic content near the top of the page, adding pointers to help new users, and grouping notifications in the right sidebar.

Description:
Today I looked at the Dreamwidth homepage and thought about what it might look like to a new user who's recently signed up, especially those who might be coming from non-LJ-like sites. (In this case, I was thinking of Google+, but it probably holds for other sites as well.) It occurred to me that the page looks a little lifeless and doesn't really point people at the stuff they are most likely to need. At the same time, I know that I (and some friends I asked, also long time LJ/DW users) don't really use the homepage, but head straight for our reading pages or the update page. I'd like to see actual stats on this, but I suspect this is a common pattern. So, what I'm going to suggest is mostly intended to be useful to newer users, but I hope it won't horribly bother older users who regularly use the homepage.

Currently the page shows:

MAIN COLUMN:
<user name="dw_news"> update
Quick update form
Inbox

RIGHT COLUMN:
Search DW
Reading list
Account stats
Tag cloud (your own tags)
Community management (required actions)
Your current theme

Here's what I'd like to suggest:

MAIN COLUMN:
Quick update form
Reading list (see notes below)
People/content discovery (see notes below)
Themes (see notes below)

RIGHT COLUMN:
Search DW
DW news (link only)
Birthdays
Inbox
Community management

Here's my justification.

1. READING LIST

Firstly, most other modern social network stream-like sites, these days, have your "stream" on the front page when you login: Twitter, Facebook, Google+, etc. New people, especially, are going to expect to see some action on the front page. A lot of new DW people I talk to don't really understand about the "reading" page and how awesome it is. So I'd like to put some of that stream of posts right in front of them, and explain why they want to go to the reading page for the full experience.

Here's what I think it should show:

* ~5 recent posts, in short form (userpic, user name, date, subject, first couple of lines of the body, comment count)
* "See more on your reading page. Your reading page lets you see all your friends' posts, etc etc..." (i.e. a short blurb about why the reading page is where the action's really at)

2. PEOPLE/CONTENT DISCOVERY

New users often seem to wonder how they can find stuff on DW. It would be good to have a bit of information with some pointers here, including eg. "latest things", searching the directory, promo communities, stuff like that.

3. THEMES

We currently show your current theme on the front page. Yawn. People generally know what their current theme is! But why not combine this with promoting new themes? Widen the "theme" box and stick it at the bottom of the main content column, and say "You're currently using theme X. Did you know DW has hundreds of themes to choose from, that you can use to customise your own journal and reading page? Check out themes Y and Z!"

4. NOTIFICATIONS

I'm going to collapse "DW news", "Birthdays", "Inbox", and "Community management actions" into "Notifications" here. These are all things that are like "Hey, this is a timely new thing you might want to pay attention to." Grouping them would be a good idea.

I think that the "DW news" thing should be reduced to a smaller link. People get the news notifications by email anyway (by default), and many have them on their reading lists. A notification that says "hey, there's a newish one" might be helpful but it doesn't need to sit there taking up prime real estate for weeks.

The rest should be obvious -- birthdays, inbox, community management, etc. All things you probably want to know about as they happen. Putting them all near each other just seems like a sensible UI choice to me.

5. ACCOUNT STATS AND TAG CLOUD

These just seem to be taking up real estate without serving much purpose, IMHO. The account stats are duplicated on your own profile page, and the tag cloud is duplicated on most people's themes (in the sidebar or wherever). Lose 'em.

I'm sure people will want to pull all this apart and put it back together differently, and I have to say, I'm not deeply committed to any particular part of this proposal, but I do want to reiterate the main point: the logged in homepage should be rearranged to be more dynamic and appealling, and to point new DW users at DW's best features and help them find their way around.

Potential drawbacks: I'm sure there are some people who are very fond of the current layout, who'd be disappointed with this. I can't really think of any other drawbacks.

Implementation: This is mostly a UI rearrangement and shouldn't require a lot of new functionality under the hood. I think it should be relatively straightforward, though it would require a few design iterations to make it really good. (I know it's not as complex as the new posting form's redesign, but it might be nice to do the iterations in a similarly public manner.)

Poll #7988 Rearrange the logged-in homepage
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
35 (57.4%)

Should be implemented with changes. (please comment)
5 (8.2%)

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
20 (32.8%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Better multilingual entry support

Area:
entries, search

Summary:
Allow entries to be tagged with the language(s) that they are composed of. This can be used to power more interesting things around the site.

Description:
Entries composed of written or spoken material (text, images of writing, audio, video) usually have one or more languages in which the material is presented. Allowing entries to be voluntarily tagged by their owners to describe the language(s) they are using might allow some interesting features to be developed based on entry tagging.

If a particular spelling appears in more than one language, specifying the language of the entry in site search could help find the thing someone's looking for.

Statistics on actual use of the site by users who speak different languages might be helpful to staff, especially if the technical barriers to offering the site in translation are overcome.

It could help users better connect with people who speak their same language, especially users whose preferred language is in a minority on the site.


What would the user interface be like? A whole long list of possible languages could a) be unwieldy, b) might also leave out languages used by actual site users (sign languages and constructed languages spring to mind as languages that might be left out of even a fairly exhaustive list of languages, and entries with embedded video might have sign language, and fannish communities are reasonably likely to include Tengwar and Klingon, and goodness knows there are probably more use cases that I know nothing of).

One way to do it might be like the tags interface, where something can be typed in, and attempt to autofill from a preset list, but accept new entries gracefully. If designed properly, unique data entered here on public entries could be logged, collated, and presented to an administrator on a regular basis for review; items that are found to be actual common languages not present on the list could then be entered.

Any site function that involves searching by language should allow for synonyms -- three different people might use "tlhIngan Hol", "pIqaD", and "Klingon" to mean the same language -- to say nothing of the typos. There should be a way to bundle known synonyms and known typos -- and also a way to override this bundling.

Another challenge is that people might not tag all their entries (to say nothing of back entries). How hard/expensive would it be to autodetect languages? Failing autodetection, could a default be set by user, like the last language they used?

Poll #7733 Better multilingual entry support
Open to: Registered Users, detailed results viewable to: All, participants: 66


This suggestion:

View Answers

Should be implemented as-is.
38 (57.6%)

Should be implemented with changes. (please comment)
4 (6.1%)

Shouldn't be implemented.
2 (3.0%)

(I have no opinion)
20 (30.3%)

(Other: please comment)
2 (3.0%)

mellowtigger: (Default)
[personal profile] mellowtigger

Title:
crosspost to Google+

Area:
crossposting

Summary:
When I post on Dreamwidth, I want a blurb added to my feed in Google+.

Description:
When I post on Dreamwidth, I want a blurb added to my feed in Google+. Not the whole post, just a few things (similar to how Livejournal crossposts to Facegook):
1) Google+ title= "Dreamwidth: (post title)"
2) Google+ image= (post icon, if any)
3) Google+ text= (first 30 words from the post) and (link to Dreamwidth post)

Poll #7726 crosspost to Google+
Open to: Registered Users, detailed results viewable to: All, participants: 65


This suggestion:

View Answers

Should be implemented as-is.
20 (30.8%)

Should be implemented with changes. (please comment)
7 (10.8%)

Shouldn't be implemented.
12 (18.5%)

(I have no opinion)
24 (36.9%)

(Other: please comment)
2 (3.1%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Option to display snippets of most-recent entry comments on reading page

Area:
reading page, comments, styles

Summary:
Allow for styles to display snippets (with context) of most recent visible comments to an entry on the reading page. It might show a small version of the comment's icon, the username, "in reply to [a comment by <username> | the entry]", the timestamp, and the raw or markup-stripped first ~255 characters.

Description:
The ability to read comments without leaving the reading page would probably be at least as powerful as the ability to expand cut tags from the reading page. I believe it would lower the barriers to interaction and entice people who would not have otherwise interacted into interacting, rather than enabling the laziness of readers and allowing readers who would have otherwise read all the comments to skip over them. It would be impractical to load a whole page of comments (complete with threading) on the reading page, however. Two or three to ten or fifteen might be reasonable.

This would be a choice made by the reader in turning on the option for their reading page style, and would not show them anything that they wouldn't be able to see by opening any entry in ?view=flat and looking at the last page of comments, so if it were implemented, it would be difficult to justify allowing a journal owner to disallow comments from their entry to be loaded on the reader's reading page. (If a journal owner had recent-comments view turned on in their own journal and a reader wanted to turn it off, ?style=mine and ?format=light both should turn it off.) People who rely on Google Analytics to track readership numbers for their specific entries might feel as though this cheats them out of page views, if there is no technical solution to track this (for readers who are not blocking Google Analytics code, which can be done easily).

The suggested form represents a compromise between loading all the comments and loading none of them, with aspects drawn from independently hosted blogs, Twitter and some of its clients, Facebook, and YouTube.

I suggest most-recent comments as the ones to display, because the first comment may not even be useful, replied-to comments can't be edited and won't change, and the only way the first comments are going to change is if they're edited or one is deleted. I suggest snippets because Dreamwidth comments can be very long. I suggest raw or markup-stripped because when you're doing snippets, there's a danger of having markup that starts but doesn't end. If the comment is longer than the bit given, there should be a clear indication that it continues, a la the Latest Things page (which also cuts off long entries).

YouTube sorts by most-recent first and allows the viewer to flip between pages of comments inline, which is a neat trick. YouTube comments can also be a pit, and I don't know how much of that is attributable to the interface, how much is the commenting community, and how much is the broadcast attitude & not-much-moderation of the video creators.

It could be a latest-comments module that is turned on with a tickybox in the styles area, and further stuff could be customized either with controls there or as advanced editing. Things like number of comments, icon display, icon size, format of timestamp, size of text, minimum/maximum height of the area given to each comment (maybe a fixed height and scroll bars would be a good idea), perhaps maximum number of characters to display (again, very long comments are possible) might be good settings to have.

I don't know if data like the username of the parent comment is a thing that is stored to be easily fetched, or whether it would have to be expensively derived each time. If it would have to be expensively derived, a regular parent link could be used. (Something really shiny from Twitter would be displaying context of the parent comment inline when clicked, if the parent is visible to the reader.)

Inline ability to reply to the comment would only be advisable if the whole comment were displayed, and even then I find it questionable. However, there are or were ways to add inline top-level commenting to LJ friends pages (not sure if it's possible on Dreamwidth) and I did not see much difference between those comments and other top-level comments. It's also possible to get comment notifications, and reply to comments that one gets the notifications for without reading any of the other comments to the entry.

Poll #7714 Option to display snippets of most-recent entry comments on reading page
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

Should be implemented as-is.
10 (21.3%)

Should be implemented with changes. (please comment)
11 (23.4%)

Shouldn't be implemented.
8 (17.0%)

(I have no opinion)
17 (36.2%)

(Other: please comment)
1 (2.1%)

flo: A lovely, purple-shaded teapot. (Default)
[personal profile] flo

Title:
Revamping the 'Export Journal' tool to allow exporting in larger time intervals

Area:
exporting, interoperability, backups

Summary:
Revamping the 'Export Journal' tool at http://www.dreamwidth.org/export so that you can export entries from your journal on a yearly basis, and also export it all as one giant file. Export options on that page could also use some clarification so that you understand why or why not to tick them.

Description:
Basically, I want to the basic export tool to allow me to export my journal as XML on a yearly basis as well, or even just all at once. Currently, the export tool at http://www.dreamwidth.org/export only allows you to export on a monthly basis, which means lots and lots of repetitive action if you post even occasionally on your journal. As far as I know, people that want to back up their Dreamwidth journals generally resort to something like LJ Archive, which is thorough, but can be inexplicably buggy, and is not at all maintained by Dreamwidth or otherwise affiliated with Dreamwidth. I would much prefer being able to export my journal with an on-site tool that I know will be fixed or improved as necessary, and I would be willing to go without exported comments if the Dreamwidth tool will provide a complete set of all my entries.

It would also be rather nice if the more esoteric options on the tool's page had more explanatory labels. Currently, this is approximately what the "Fields" options look like:

- ID Number
- Event Time (from your clock) *
- Log Time (from system's clock) *
- Subject
- Event *
- Security Level
- Allow Mask *
- Current Mood & Music

Some of these fields (the unstarred ones) are fairly self-explanatory. The rest are somewhat confusing to me-- "Event Time" and "Log Time" seem self-explanatory at first glance, but then you also have "Event", and before I actually looked at an export file, I honestly wasn't sure what all those fields would mean when taken together. "Allow Mask" is also really badly named, and probably should not be an option at all, since that field is basically the bit that is used to determine whether an entry is public or access-only. Not exporting that field just removes part of the distinction made between private and public entries in the export file, which really doesn't serve any purpose since the tool currently exports everything. A fine-grained option to control what is exported would be nice, but it probably should not be at all related to what fields get exported.

Another confusing option on the page is: "Don't translate between encodings". Is this something an end user is supposed to just know? I know what encodings are, and that option does not really tell me exactly what it does. Does ticking the option mean that it will just leave any entries that are not encoded as X (where X is the encoding you selected from the preceding combo box) as they currently are? Is this an option that's more for debugging or troubleshooting export files that don't import elsewhere correctly? Should it even be on the page at all?

As far as using the tool goes...well. There is nothing on the page that indicates that the tool will only export by month, so unless you got to it from the FAQ, you won't even know about that. When I tried putting in just the year to see if I would get an explanatory error, it basically just gave me an empty CSV or XML file named after the year. Putting in the wrong month/year combination also gave me an empty file, which, remember, I won't know about until I actually look within the file. Considering that the tool is supposed to let you export entries, I really think it should let you know when your settings mean that you will not be exporting any entries at all.

In summary, what I want is for the export tool to
a) Allow you to export entries by year
b) Allow you to export all your journal's entries at once
c) Provide understandable and useful options that will not make your export useless or incomplete in ways that you did not mean (e.g. if, for some reason, you do not select "Event", none of your entry text will be added to the export file)

If there is a question of the tool putting strain on the servers, the number of times that free users can export their journals can be restricted (e.g. once a month, once every couple months, etc).

Poll #7709 Revamping the 'Export Journal' tool to allow exporting in larger time intervals
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

Should be implemented as-is.
20 (44.4%)

Should be implemented with changes. (please comment)
9 (20.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (35.6%)

(Other: please comment)
0 (0.0%)

robotech_master: (Default)
[personal profile] robotech_master

Title:
Add your site to addthis.com

Area:
posting

Summary:
Could you go to the following website and use it to submit a listing for Dreamwidth to the AddThis link sharing rouser plug-in? There is a listing for LiveJournal, but not one for Dreamwidth – and since I have Dreamwidth set to cross post to LiveJournal, I'd like to be able to post anything I would want to post there here instead.

http://www.addthis.com/services/submit?

Description:
This would mainly involve making sure that Dreamwidth is Oexchange compatible, and submitting the URL to the site descriptor.

Poll #7708 Add your site to addthis.com
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
6 (14.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
6 (14.0%)

(I have no opinion)
31 (72.1%)

(Other: please comment)
0 (0.0%)

pendrecarc: Woman holding a hooked hand (Default)
[personal profile] pendrecarc

Title:
Offer a "Preferred pronoun" field on the profile page

Area:
Profile

Summary:
It would be helpful to get a "preferred pronoun" field on the profile screen in addition to the "gender" field. This would facilitate discussion and linking to other users' posts. It would be important to include a "Rather not say" option, of course.

Description:
It can be difficult to link to other DW users' posts or mention other users if you don't happen to know which pronoun they prefer. Not everyone is comfortable asking You can always choose something gender-neutral or talk around it, of course, but that can be syntactically awkward, and whenever possible I want to respect other users' preferences. If someone has a gender selected, that can provide a clue, but it's not a guarantee, and of course not everyone does.

Having a space in the profile to specify a pronoun seems like a quick fix. The field could be free text if compiling a list of possible pronouns is problematic, but either way it should include the (default) option not to display a pronoun.

Poll #7556 Offer a "Preferred pronoun" field on the profile page
Open to: Registered Users, detailed results viewable to: All, participants: 116


This suggestion:

View Answers

Should be implemented as-is.
52 (44.8%)

Should be implemented with changes. (please comment)
23 (19.8%)

Shouldn't be implemented.
17 (14.7%)

(I have no opinion)
23 (19.8%)

(Other: please comment)
1 (0.9%)



Edited on 10/8/2011 to add that I got some of my facts wrong in this post re: the existing profile options, due to some confusion over different sites. Also, I explained the possible benefits of this very poorly. It's not just an issue of social ease for those of us linking to other users; it's also, and far more importantly, about being aware of how users of this site want to be approached. Based on comments, if this is implemented (as I still think it should be) it's very important that the field be free text.
adalger: Earthrise as seen from the moon, captured on camera by the crew of Apollo 16 (Default)
[personal profile] adalger

Title:
Show how things ended up on your Network page

Area:
Network page (paid accounts)

Summary:
Your Network page is like a box of chocolates. You never know what you're going to get. It would be nice, though, to at least know how you got it. I'd like to have a link on each entry telling you how many of your subscribed journals see the entry, followable to see a list.

Description:
When you read your network page, you have no idea specifically how any entry got there. It would be informative to have an immediate indication of how many of your reading-page journals subscribe to the entry, as this might be an indicator of how interesting it will be to you. Ideally, this should appear near the beginning of the entry.

It should be structured as a link, so you can follow the link to get a list of those journals. I see no privacy concern here, as that information is available already on the profile pages of journals. I do see a potential argument that it's "too facebookish", but I don't think that's necessarily a bad thing in this particular case.

Poll #7538 Show how things ended up on your Network page
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
34 (59.6%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
4 (7.0%)

(I have no opinion)
19 (33.3%)

(Other: please comment)
0 (0.0%)

ratcreature: RatCreature's toon avatar (Default)
[personal profile] ratcreature

Title:
allow posters in communities to remove tags from their own posts

Area:
communities

Summary:
I think it would be useful if the poster in a community was allowed to remove tags from their own posts, even if tag creation rights are admin only, because then an admin wouldn't have to edit in case of mistakingly picked tags.

Description:
I have a community set up so that only admins can create new tags, because I'm fussy about the formatting of tags, but the rights are such that in the second tagging option it's picked that all members can add existing tags to posts. So unless a new tag is needed the tagging is done by the posters themselves, rather than needing admin action.

However when a member accidentally picks a wrong tag for their post, maybe due to the auto-complete completing wrongly, or slipping a line in the list or such without noticing right away, the poster can only add the correct tag later, but not remove the wrong tag. So they then need to ask an admin to fix their tags for them.

I think it would be useful if posters could remove tags from their own posts when they edit them.

Poll #7088 allow posters in communities to remove tags from their own posts
Open to: Registered Users, detailed results viewable to: All, participants: 70


This suggestion:

View Answers

Should be implemented as-is.
41 (58.6%)

Should be implemented with changes. (please comment)
16 (22.9%)

Shouldn't be implemented.
2 (2.9%)

(I have no opinion)
9 (12.9%)

(Other: please comment)
2 (2.9%)

Profile

Dreamwidth Suggestions

April 2017

S M T W T F S
      1
23456 7 8
9 101112131415
16171819202122
23242526272829
30      

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom