dw_suggestions | Entries tagged with site: usability

Title:
Community Membership Log

Area:
communities, community administration

Summary:
For community administrators: Log relevant community membership changes, such as new members joining, moderated membership activity, members leaving, attribute changes (post moderation, post permission, moderator, admin), and bans.

Description:
Some of these attributes are already logged for site administrators, but it would be useful to have them logged for community administrators.

Invitation -- username of invitee, server time of action, username of admin making the invitation.

Join -- username of member, server time of action, and whether it was in response to an invitation/through the member moderation (and who approved the membership if so).

Membership rejection -- username of applicant, server time of action, username of admin rejecting the application.

Invitation expiration -- username of invitee, server time of invitation & expiration, username of admin who invited them.

Attribute change -- username of member, server time of action, the change (gained/lost post, entry moderation, moderation power, admin power), and username of admin.

Ban/unban -- username, server time of action, ban/unban, username of admin.

Departure -- username, server time of action, and username of admin if this was an admin action.

Should reading page subscription/unsubscription also be logged?

Poll #9396 Community Membership Log

Open to: Registered Users, detailed results viewable to: All, participants: 62

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
24 (38.7%)

(Other: please comment)
0 (0.0%)

azurelunatic

Title:
Community Entry & Comment Action Log

Area:
communities, community moderation

Summary:
For community administrators: Log relevant entry and comment activities. This could include things like deleting entries, deleting comments, screening/unscreening comments, freezing/unfreezing comments, editing entries, and tag editing.

Description:
One challenge for community administrators is sometimes keeping track of various activities in their community. Different community populations require different levels of admin attention, and sometimes an administrator does not realize they need to know about a specific action in their community until something happens and they're left trying to sort out what exactly happened and who they need to talk to.

These are all community actions that currently leave little trace in the system, but can be crucial to sorting out what happened and why.

Entry deletion -- some communities ask that their members not delete their entries. Some communities ask that only one specific administrator delete any entries. Sometimes, as in the case of communities like dw_suggestions, a deleted entry means administrative work to track down the entry and reconcile the public-entry-to-private-admin-entry counts. Entry deletion should log the username of the entry owner, the server time the entry was initially posted to the community, the entry's subject and first ~100 characters (raw), the time of entry deletion, the username of the party who deleted the entry (and possibly their position: self or admin), and whether the entry was marked as spam.

Comment deletion -- some communities ask that comments with problems be left in place for an administrator to handle. Sometimes it is accepted for the person who left the comment to think better of what they said and delete their comment, but it is frowned upon for the entry poster to delete a comment even though they have the power to do so. Comment deletion should log the username of the comment owner, the subject and first ~100 characters, the server time the comment was initially posted, the entry (and thread, if applicable) in which the comment was posted, the username of the party who deleted the comment (and possibly their position: self, entry poster, admin), the time of the comment's deletion, and whether the comment was marked as spam.

Comment screening/unscreening, freezing/unfreezing -- I have seen entry poster vs. community administrator freezing and screening wars before, and they are not pretty. I did not know that I would want this logged until it happened to me. This should log the username of the comment owner, the subject & first ~100 characters, the server time the comment was initially posted, a link to the comment & thread (because sometimes you want to go straight there, sometimes you want the whole thread, possibly the direct parent too), what the action was, and the username of the person who did it (and possibly their position: entry poster or admin).

Entry editing -- I'm less concerned with editing of the entry text in this context as I am with things like editing to turn off comments, or that it would be really nice to log when community admins bump the NSFW setting or security. But other community admins may have different concerns. This should probably log the username of the entry poster, title & first ~100, server time of post, server time of edit, who edited it (and possibly position: entry poster or admin), and the attributes that were edited. Subject edits could probably display old subject & new subject. Body edits could display ... net change in character count? (Other community admins, please weigh in on what would be useful.) Entry attributes should display old value & new value if there was a change.

Tag editing -- this could be useful for mistaken tagging or tag vandalism, like if someone accidentally detags an entry, or selects all tags for an entry and saves it. Log should include information to identify the entry (username, server time of posting, subject & first ~100, link), the old tags, the new tags, and the username & position (non-member, member, entry poster, admin), and server time of change.

I'm not sure that comment editing needs to be logged, because there already exist notifications that can be emailed, admins from paid communities can subscribe to all comments (including all edits), and people edit comments a lot (and it could clog up the logs).

Anything else?

Poll #9395 Community Entry & Comment Action Log

Open to: Registered Users, detailed results viewable to: All, participants: 52

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (40.4%)

(Other: please comment)
0 (0.0%)

ratcreature

Title:
make managing your tracking notifications easier

Area:
tracking

Summary:
It would be great if in the long list of notifications of things you track it would be highlighted when a tag you tracked had vanished (edited or made private or such), or an entry you tracked was deleted, so you can see that one of your notifications is not working anymore. Also it would be great if the list had other sort options rather than chronological, e.g. by type (tracking a thread, tracking comments to an entry, tracking an entire journal etc.) and sorted alphabetically by journal name for example.

Description:
I don't track that many things on DW yet (only a bit over 60 items so far), but on LJ that list has gotten very long, and it is really hard to find things. I could have 1000 tracking notifications on DW and all are just one list.

Among the list I often don't notice that a tag I'm tracking (e.g. for a series I'm following) has been changed, and that that is why I don't get notifications anymore, rather than the WIP having been abandoned. That tag changing actually happens with disturbing frequency as some people like to reorganize their tags (e.g. adding a "series:" in front of the title tag once they have more than one). So it would be great if any defunct notifications could be highlighted in some way, so I don't have to spot them the hard way in a long list.

It would also be good to be able to sort that list in general, instead of the display being always just chronological. I'd find a sorting by the type, e.g. journal update, comments to an entry, comments to a thread, useful, also the possibility to sort the list by the journal name (for communities I'd like them sorted for the comm name rather than the poster). As control I imagine something like a sort button on top saying "display chronological/alphabetical/by type" that you can click like in other places that show you long lists.

Poll #9375 make managing your tracking notifications easier

Open to: Registered Users, detailed results viewable to: All, participants: 66

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
51 (77.3%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (21.2%)

(Other: please comment)
1 (1.5%)

thnidu

Title:
make list of allowable HTML easier to get to

Area:
entries and comments

Summary:
Make it easier for the user to see what HTML tags are OK to use, *while they are writing or editing a post or comment*.

Description:
In order to check "can I use this HTML tag?" or "What's the name of that tag again?", a user who is composing or editing a post can scroll down to the list given below the post... unless it's a DW-specific tag. For that, they have to (as far as I can tell)
1. open up their home page in a new tab
2. click on "Help/FAQ"
3. open one of three different pages listed there (here in the order they appear in):
- a. What Dreamwidth-specific markup/HTML tags can I use? (a short list of those three tags, with links to further information about them such as available attribute)
- b. What HTML tags can I use on Dreamwidth? (a list with detailed examples)
- c. What HTML can I use in my entry? (a simple compact list of the allowed HTML tags, plus a link to page "a" above (Dreamwidth-specific markup/HTML tags)

Two suggestions:
1. After the list of general HTML tags that you have below the composition pane for a *post*, add a list of DW's local HTML tags, with something like "Dreamwidth-specific tags:".
2. Also,
- Make a separate page with those two lists -- not just allowable general HTML and a link the user has to follow to see the DW-specific list. Include
-- the "learn more" links that you already have on "What Dreamwidth-specific markup/HTML tags can I use?",
-- and a link to the detailed list with examples that is "What HTML tags can I use on Dreamwidth?"
- Put a link to that page in the *Reply* area, maybe under the composition pane just to the right of "Check spelling during preview", something like this: [Allowable HTML]. The link should open on a separate page.

I've been hand-coding HTML for decades, but even so I appreciate having a list of the HTML that DW accepts at the bottom of the entry window. And I would appreciate even more having an easily accessible list of your site-specific HTML tags, which I often do not remember; for example, exactly how to add a userhead and link to the name of a user on another site.

Poll #9373 make list of allowable HTML easier to get to

Open to: Registered Users, detailed results viewable to: All, participants: 68

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
57 (83.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (16.2%)

(Other: please comment)
0 (0.0%)

cesy

Title:
Order subscription filters by name

Area:
filters, reading page, subscriptions

Summary:
On the Manage Filters page, http://www.dreamwidth.org/manage/subscriptions/filters, order the filters by name

Description:
The list of filters is currently ordered by when you created them, so if you weren't particularly logical about setting up your subscription filters, http://www.dreamwidth.org/manage/subscriptions/filters can show a bit of a mess in the drop-down. Rather than having to re-create them all, I'd love it if they could be sorted by name rather than creation date. It's already possible to rename a filter, so this would allow people to order them however they wanted - if you want to keep them in creation order, just stick numbers on the front.

Poll #9370 Order subscription filters by name

Open to: Registered Users, detailed results viewable to: All, participants: 63

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
37 (58.7%)

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
20 (31.7%)

(Other: please comment)
0 (0.0%)

sincere

Title:
Making circle changes from the hover menu should be less easy

Area:
entries

Summary:
It is currently too easy to accidentally make circle changes through the hover menu, accidental or otherwise. I propose changing the current two links that require no confirmation before acting to one link that will redirect to the Add to Circle or Manage Subscription page with full text options.

Description:
Several times in the last two weeks alone my mouse has passed, either purposefully or accidentally on the way to clicking something else, over someone's usericon. The hover menu doesn't open until the instant I am attempting to click somewhere else, and now I have clicked on one of the many links in the hover menu. Immediately I have subscribed to someone's journal, unsubscribed from someone's journal, granted someone access to my personal entries, or removed someone's existing access to my personal entries. This simple misclick can result in as many as two email notifications to let someone know that I changed their status -- when I had no intention of doing anything like that.

It's embarrassing to accidentally grant access to someone you're just talking to casually on a community, and even more embarrassing to then go "Uh, sorry, never mind" and take it away again.

I don't see why the hover menu makes this so easy. This requires only a single click and it's just done, but when I do it on the profile page, where I am much less likely to click on those links accidentally, it takes me to a separate page going "Are you sure?" first.

In addition, the hover menu has a lot of text on it, and it appears and disappears very quickly. Once I misclick, I usually have to hover over the icon again 3-4 times to see what I changed, and then to get my mouse to the link to change back again.

My solution to these problems: Replace the "Subscribe/Unsubscribe" and "Grant access/Remove access" links with just one link, which will redirect users to the existing Add to Circle or Manage Subscription pages (depending on their current status in your circle). This both removes the accidental adding problem, and makes it easier to use.

Potential pros:
+ No more accidental circle changes. Big pro for me.
+ Fewer links means less chance for misclicking in general.
+ Users won't have to sort through as much text to find the link they want.
+ Seems more accessible for readers who have reading or clicking difficulty than providing so many options on the tiny, there-and-gone-again hover menu.

Potential cons:
+ Some ease of use removed, requiring an extra page load to change circle status.
+ If there is any accessibility reason for the pile of links and text on the hover menu, that should be taken into account.
+ If you were hoping to meet your future spouse via a misclick granting them access and them falling in love with you while reading your private meanderings, this may reduce the odds of that happening.

Poll #9258 Making circle changes from the hover menu should be less easy

Open to: Registered Users, detailed results viewable to: All, participants: 69

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
9 (13.0%)

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

Shouldn't be implemented.
23 (33.3%)

(I have no opinion)
18 (26.1%)

(Other: please comment)
3 (4.3%)

lannamichaels

Title:
Rename "Upload Icons" to "Manage Icons"

Area:
Navigation

Summary:
Change the text of the "Upload Icons" link in the navigation to more accurately reflect the use for that page.

Description:
In the links, the link to manage icons is called Upload Icons. Other places where you can change things are called Edit and Manage. "Upload Icons" makes it sound like that's where you go to upload, but somewhere else to Manage them. I suggest the text of the link be renamed to "Manage Icons".

Poll #9094 Rename "Upload Icons" to "Manage Icons"

Open to: Registered Users, detailed results viewable to: All, participants: 91

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
73 (80.2%)

Should be implemented with changes. (please comment)
1 (1.1%)

Shouldn't be implemented.
1 (1.1%)

(I have no opinion)
16 (17.6%)

(Other: please comment)
0 (0.0%)

pleonasm

Title:
Move Delete Entry button away from Save Entry Button

Area:
edit entry page

Summary:
Move the Delete Entry button on the Edit Entry page so that it is not right next to the Save Entry button.

Description:
LJ recently made this small change so that the Delete Entry button is not right next to the Save Entry button on the Edit Entries page. Now, I know we're testing a beta Post Entries page, but I haven't seen the same for the Edit Entries page. If we're going to be using the Edit Entries page for a while, I'd like to see the Delete Entry button moved like it has been moved on LJ. This makes it much harder to delete an entry by accident. Of course, it would be great if it didn't change the tab order, either. Move the Delete button left, move it right -- the point is separating it from the Save Entry button better.

Poll #9093 Move Delete Entry button away from Save Entry Button

Open to: Registered Users, detailed results viewable to: All, participants: 74

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
55 (74.3%)

Should be implemented with changes. (please comment)
1 (1.4%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (24.3%)

(Other: please comment)
0 (0.0%)

sepdet

Title:
Tweak login button for ham-fisted mobile users.

Area:
Control strip

Summary:
Reposition login/logout button with some space around it.

Description:
I'm not quite sure of the best way to fix this, but I keep hitting the Logout button when I try to click the "reading" link below it on the control strip at the top of my journal. I have arthritis and an iPad, so I'm testing accessibility and mobile issues for you at the same time!

For both audiences, it would be better not to have a frequently-accessed link right beneath "logout". Maybe the logout button could be moved to the right, as it's easier to hit the middle of the word "Reading" horizontally than vertically.

There's probably some way to tab to it, but I have a hunch this wouldn't be too hard to adjust. Of course, that brings in a bit of the dreaded whitespace, which makes sites easier to browse via mobile devices but tends to make pages look ugly.

Poll #9085 Tweak login button for ham-fisted mobile users.

Open to: Registered Users, detailed results viewable to: All, participants: 62

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
24 (38.7%)

(Other: please comment)
0 (0.0%)

azurelunatic

Title:
Useful control links on search page

Area:
search, entries

Summary:
When searching your own entries, get additional useful links, such as edit entry, edit tags. This could possibly also include control links for entries not in your own journal, if you have permission to retag in that journal, or for communities where you are an administrator.

Description:
Sometimes, when you're searching entries, you're searching for the purpose of editing the entry or its tags. In those cases, you have to first open the entry, then go to edit the tags or the entry.

It could be helpful to offer links to edit the entry or tags.

User interface-wise, the links could possibly be fit in without disrupting the flow too much or making it take up any more lines:

Current:

[personal profile] azurelunatic: 53 tweets for 2011-2-7
... , and jdn. Monday, 2015: @mishacollins Who's having problems with their polypodes? Monday, 2017: Pie doesn't have tentacles, but cupcakes do. http://www.etsy.com/listing/61287471/cupcaketapus Monday, 2018: HEAVENS ABOVE, SEX WITHOUT LOVE Monday, 2024: @ ...
Tags: twitter
Posted: 2011-02-07 23:55:00

Proposed:

[personal profile] azurelunatic: 53 tweets for 2011-2-7 (edit)
... , and jdn. Monday, 2015: @mishacollins Who's having problems with their polypodes? Monday, 2017: Pie doesn't have tentacles, but cupcakes do. http://www.etsy.com/listing/61287471/cupcaketapus Monday, 2018: HEAVENS ABOVE, SEX WITHOUT LOVE Monday, 2024: @ ...
Tags: twitter (edit)
Posted: 2011-02-07 23:55:00

Poll #9058 Useful control links on search page

Open to: Registered Users, detailed results viewable to: All, participants: 52

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (40.4%)

(Other: please comment)
0 (0.0%)

thnidu

Title:
"Delete all" should not be option in inbox subfolders

Area:
inbox interface

Summary:
It's not clear to me whether the "... All" buttons in Inbox subfolders such as "unread" apply only to the messages in that folder, or to all messages, and I'm not about to test it.

Description:
When I go to my inbox and click on any of the subfolders, such as "New People" or "Unread" (see req. #12097), I still have the "mark all read" and "delete all" buttons at the top and bottom of the list.

Do these really affect *all messages*, or just the ones in the current subfolder? If the latter, I urge you to relabel them, e.g. "Delete all these" and "Mark all these read", to make it clear that they do not apply to ALL the messages.

Poll #9056 "Delete all" should not be option in inbox subfolders

Open to: Registered Users, detailed results viewable to: All, participants: 51

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
24 (47.1%)

Should be implemented with changes. (please comment)
8 (15.7%)

Shouldn't be implemented.
2 (3.9%)

(I have no opinion)
17 (33.3%)

(Other: please comment)
0 (0.0%)

rainfall

Title:
Beta Icon Browser: Organize by Keyword instead of Upload Order

Area:
beta icon browser

Summary:
To either have an option to switch between upload order and keyword order (as the normal icon viewer has) or to swap from an upload order to a keyword order.

Description:
I don't think it's really human nature to look for icons by the order in which we uploaded them: we don't remember that. We do remember icons, especially if we categorized them for organization. (Say, by fandom, or by color, or by mood!) I think that keyword order would be a more human-accessible way of organizing icons.

It has been pointed out to me that this would cause some icons to repeat with multiple keywords -- but I think that would be fine, since it wouldn't add to load time, but MIGHT add to user convenience.

I assume that changing the sort method would be fairly simple, so I would be willing to do this myself if there's interest from other users.

Poll #9004 Beta Icon Browser: Organize by Keyword instead of Upload Order

Open to: Registered Users, detailed results viewable to: All, participants: 75

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
50 (66.7%)

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

Shouldn't be implemented.
3 (4.0%)

(I have no opinion)
11 (14.7%)

(Other: please comment)
0 (0.0%)

amber

Title:
the ability to select multiple tags when tracking users and communities

Area:
tracking communities and journals

Summary:
Being able to select multiple tags at once on the tracking page for users and communities.

Referring to this page:

http://www.dreamwidth.org/manage/tracking/user?journal=dw_news

(using dw_news as an example)

Description:
When adding or removing tags from the tag page or an entry, users can type tags or select from the drop-down menu, and when editing tags the ability to select or delesect multiple with shift or ctrl clicking is incredibly useful.

I was wondering if something like this could be implemented when selecting tags to track for a community or journal? As the current system stands, if I wish to receive notifications a community with tags for, say, multiple pairings, and I want to track at least fifteen of those tags, I have to select one from the dropdown menu, track it, select another, track it, etc. It isn't a major inconvenience but especially now that I am retracking a lot of communities and users that have imported from LiveJournal, I would prefer to be able to mass-select a whole bunch of tags. I feel like maybe this is a feature that would also be appreciated by the LiveJournal rpers who have recently crossed over.

The reason I mention shift/ctrl clicking is because I feel like it is intuitive and requires very little explanation on the page, and it is a system already in place when it comes to tagging entries. I think being able to type something and see the options that appear (i.e. typing "character" and getting all tags that include the word character) would be incredibly helpful for communities or users with many, many tags especially if they are making use of the tiered tag system.

The potential drawbacks that I can see...

I don't know enough about code to be able to say if this is a large recode job, but it feels like the code used for selecting tags in the "edit tags on this entry" pages is different to the "track this community" pages.

Clutter: a small dropdown box is simple and takes little room. This idea may require more space on the page to be able to enter or select tags.

Users may accidentally select more or incorrect tags to track and because it is a more "intrusive" feature than simply tagging an entry (because it send the updates to your email or inbox) this could annoy or upset people.

Poll #9003 the ability to select multiple tags when tracking users and communities

Open to: Registered Users, detailed results viewable to: All, participants: 62

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
23 (37.1%)

(Other: please comment)
1 (1.6%)

montuos

Title:
Mobile page/regular page toggle button

Area:
usability

Summary:
I think it would be a good idea to have a toggle button to switch back and forth between a mobile page and its regular counterpart.

Description:
It has been clearly demonstrated that different users and different mobile devices have different needs and requirements. Sometimes it is desirable to be able to switch back and forth between a mobile page and its regular counterpart (wherever different versions exist) quickly and easily. A toggle button at the top of the page could solve this.

See http://dw-suggestions.dreamwidth.org/1286067.html for comments regarding usage that spawned this idea.

Poll #8903 Mobile page/regular page toggle button

Open to: Registered Users, detailed results viewable to: All, participants: 79

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
55 (69.6%)

Should be implemented with changes. (please comment)
1 (1.3%)

Shouldn't be implemented.
1 (1.3%)

(I have no opinion)
22 (27.8%)

(Other: please comment)
0 (0.0%)

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

View Respondents

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%)

turlough

Title:
Confusing display settings for entry/comment pages

Area:
entries, display

Summary:
The settings for "Entry View Style" and "Comment Pages" (under My Account Settings: Display) are sufficiently alike to be confusing and should be reworked into one setting for how you see your own pages and another for how you see other people's pages.

Description:
The Display tab under My Account Settings has two different settings that concern the same thing.

Both "Entry View Style" and "Comment Pages" govern the way you see entry/comment pages. The options they offer are almost, but not entirely, alike - "Entry View Style" lets you choose between viewing both your own and other people's pages in Original Style / Site Skin / My own style / Light format, and "Comment Pages" lets you choose between viewing comment pages (presumably other people's) in your own journal style or the journal owner's style by way of a tickybox - which means that I never feel completely sure that the settings I've chosen will give me the result I desire.

It's very confusing and I feel it would be so much easier if these two settings were reworked into a setting for how you see your own entry/comment pages and a setting for how you see other people's entry/comment pages.

I would suggest that the options for your own pages should be My Journal Style / Site Skin / Light Format, and that the options for other people's pages should be Original Journal Style / My Journal Style / Site Skin / Light Format.

Poll #8857 Confusing display settings for entry/comment pages

Open to: Registered Users, detailed results viewable to: All, participants: 52

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (28.8%)

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

Shouldn't be implemented.
8 (15.4%)

(I have no opinion)
18 (34.6%)

(Other: please comment)
7 (13.5%)

deborah

Title:
make a more direct link to support request from feed profile page

Area:
support

Summary:
Somebody who is requesting a changed URL for a feed doesn't need to read the FAQs for support, they need to go directly to the link for making a support request.

Description:
On the profile page for a feed account, we have the text "If this feed has stopped updating because its location has changed, please contact Support to have the location updated instead of creating a new feed." "Support," in this case is a link to the support portal (http://www.dreamwidth.org/support/), which rightfully starts with all of the FAQs, Known Issues, etc., and has "make a support request" way down on the bottom.

However, somebody who clicks on the link "please contact support to have the location updated" doesn't need to read all the FAQs; they just need to contact support. It should take them directly to the form.

In fact, ideally, it should take them to a pre-populated version of the form, which says something like "the URL for the syndicated feed sample_feed has been changed. Please paste the new URL below."

(And if we do all that, then the linked part of the above text shouldn't just be the word "support" but the more informative link text "contact support to have the location updated". That's just a change of where the [/a] those.)

Poll #8832 make a more direct link to support request from feed profile page

Open to: Registered Users, detailed results viewable to: All, participants: 60

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
54 (90.0%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (10.0%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Manage Circle success page: separate links to access filters and subscription filters

Area:
site interface

Summary:
When you've made some changes on http://www.dreamwidth.org/manage/circle/edit, you get a success page with other useful links. There's a link called 'Edit posting and reading filters' [http://www.dreamwidth.org/manage/circle/editfilters]. I'd like a proper link to reading filters [http://www.dreamwidth.org/manage/subscriptions/filters] be added to the list.

Description:
.

Poll #8385 Manage Circle success page: separate links to access filters and subscription filters

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (18.0%)

(Other: please comment)
0 (0.0%)

denise

Title:
Support instructors/teachers/professors using DW for class-related projects

Area:
posting, communities, using DW to conquer the world

Summary:
We get at least three or four instructors per semester asking for promo codes for account creations for their classes (which we're always happy to give!) Since DW is so well-suited to keeping class journals, submitting writing assignments, or requiring class participation, I'd love to be able to code some more support for academic use.

Description:
Obviously each teacher's use of DW would be different, depending on the type of class they're teaching and the level at which they're teaching it (high school, undergrad, graduate work, adult enrichment, etc). This suggestion is less "we should add this" and more "we should brainstorm what we can add that would actually be most helpful".

I'm basically proposing a new category of accounts: "instructor accounts" or "academic accounts" and "student accounts" or "learner accounts" (names obviously subject to change, yadda). This will allow us to set different capabilities for these accounts.

The "academic package" would consist of:

* one promo code per class/class section;
* one "academic community" account per section, with slight changes to the standard community model to make them more appropriate for teacher/class interaction;
* one (or more if co-taught or if class has a TA) "instructor account" to be the admin of the community (or the instructor could use their standard DW account, but all of the instructors I know don't want their students finding their regular DW account!)
* a number of "student accounts" created via the promo code, where the students can choose their own usernames and migrate the student account to a standard account later if they'd like.

Things I can think of, off the top of my head:

* the ability for the instructor to "clear out" a community's posts and comments, moving them to some form of archive (essentially a community rename?) each semester/quarter/marking period/etc in order to store each semester's classwork separately and start each semester with a blank slate

* ability to force a student account created with a specific promo code to be subscribed to/a member of the community for the project, without having to check the checkbox during account creation

* ability to designate an instructor account for each "academic package" that will automatically subscribe to any account created from the promo code (so the instructor won't 'lose' students or have to get them to submit their username to the instructor through some other method)

* ability for the instructor to subscribe to all posts and comments made in the community (without the comm needing to be a paid community, I mean)

What other things would instructors using DW for academic/teaching purposes want to see, or would find useful?

(Edited to remove poll #7997, since this is more of an information-gathering entry than a suggestion!)

azurelunatic

Title:
User-specific pages should show username in the browser title

Area:
icons, memories making things make sense

Summary:
The browser title for user-specific pages like icons and memories should also include the username, especially when it's not your own journal.

Description:
Currently, the /icons page (for example, http://azurelunatic.dreamwidth.org/icons ) merely has "Icons" as the page title. Something like "Icons - username" might be more useful, especially if someone has multiple tabs open with multiple people's icon pages. Memories (/tools/memories?user=example) has the same problem.

I prefer little-endian (most-specific first, out to least-specific) page titling, for example "Icons - azurelunatic - Dreamwidth" although places like the profile page have the username first in the title and then the specific page title, so it should probably be standardized across the site at least as far as pages in the main site style go.

Poll #7989 User-specific pages should show username in the browser title

Open to: Registered Users, detailed results viewable to: All, participants: 74

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
57 (77.0%)

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

Shouldn't be implemented.
2 (2.7%)

(I have no opinion)
8 (10.8%)

(Other: please comment)
0 (0.0%)

Dreamwidth Suggestions

Community Membership Log

Community Entry & Comment Action Log

make managing your tracking notifications easier

make list of allowable HTML easier to get to

Order subscription filters by name

Making circle changes from the hover menu should be less easy

Rename "Upload Icons" to "Manage Icons"

Move Delete Entry button away from Save Entry Button

Tweak login button for ham-fisted mobile users.

Useful control links on search page

"Delete all" should not be option in inbox subfolders

Beta Icon Browser: Organize by Keyword instead of Upload Order

the ability to select multiple tags when tracking users and communities

Mobile page/regular page toggle button

Compact Comment View

Confusing display settings for entry/comment pages

make a more direct link to support request from feed profile page

Manage Circle success page: separate links to access filters and subscription filters

Support instructors/teachers/professors using DW for class-related projects

User-specific pages should show username in the browser title

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate