ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support Board: add exclude filter

Area:
support, site interface

Summary:
The Support Board has a filter to show you all requests from category Z. I'd like the opposite of that: show me all requests but the ones from category Z.

Description:
The board could certainly do with more complex filter options such as letting you filter and exclude multiple categories but that's a discussion for when the board will get a full redesign. I think the exclude Z filter would be a simple yet still practical option for now.

Poll #18203 Support Board: add exclude filter
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (37.5%)

(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:
View entryprops for your own journal/administrated community

Area:
entries, self-service support

Summary:
Staff and senior support have the at-need ability to view some of the troubleshooting information attached to entries; this information could be useful to the journal owner.

Description:
All entries have under-the-hood information called "entryprops" (short for "entry properties") attached to them. Staff/senior technical support can view these at need.

Usually there's no need to view this information, but sometimes there's a simple question (like: did all my icon information successfully make it over when I imported? Generally the importer gets this right, but it's usually more reassuring to see for yourself) that could be answered. (And doubtlessly if it were readily available, there would be more helpful uses for it floating around.) It also strikes me as information that would be useful to a community administrator, if it's available to journal owners.


How would it be viewable? (For all of the cases below, this would only be for the journal owner/community admin; if someone didn't have permission to see if they would get an error.) I have a few thoughts.

1) Create a page where you can enter the link to an entry in your own journal (or your community), and the properties are displayed. This is simple and pretty straightforward, does not require monkeying around with any existing pages, but not entirely friendly.

2) Create a URL argument (like the ?view=flat that you can add after the entry in the address bar) to display it on/from the entry. This would be reasonably friendly, but would probably take a lot more developer doing, and you'd have to look up how to do it if you didn't remember and needed to use it. (Depending on what was less of a pain to develop, I would see this as either adding information to the existing display, or going to a new location containing the information and a link back to the regular view of the entry.)

3) Have a little link/toggle near the rest of the entry information (depending on which was less of a pain to develop as described above), labeled "advanced entry information" or similar, to make it discoverable by people who don't already know to look it up.


Questions about the advisability:

1) Is there enough need for this information that someone couldn't just go ask Support? Senior support could tell people better than I could how often they get requests that require entryprops information.

2) Would this answer more questions than it would cause? It would not be fair to Support to release a feature that would cause a deluge of "What's a ____ and why do ____???!?!" questions. If this is implemented, someone grab me and I will write docs.

3) Would any information be revealed that a community administrator shouldn't have?

4) Would any information be revealed that is Dreamwidth-internal and a user shouldn't have? (I doubt it, but I ask for completeness; staff would have to answer this one.)




Development: This sounds like the sort of high-complexity, low-impact project that might sit for 10 years without being claimed.

Poll #12339 View entryprops for your own journal/administrated community
Open to: Registered Users, detailed results viewable to: All, participants: 38


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (76.3%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support: widen the 'Reference FAQ' drop-down menu

Area:
support

Summary:
When you answer a support request, you have the possibility to reference a FAQ. To help you do this, there is a drop down menu listing all the existing FAQs. Some FAQs have long titles and the menu truncates them. I suggest it be made a little wider to make it easier to find the correct FAQ.

Description:
Maybe 25 characters longer.

Poll #9855 Support: widen the 'Reference FAQ' drop-down menu
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (30.2%)

(Other: please comment)
0 (0.0%)

deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
[personal profile] 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


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

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] 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!)
ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support: create category for feeds

Area:
support

Summary:
Requests about feeds currently go into the General/Unknown category. I think it would be useful if they went into their own category as most requests dealing with feeds require special privs most volunteers don't have.

Description:
It would allow volunteers to opt out of notifications about requests they can't answer and I believe help volunteers with the necessary feed-related privs identify more easily requests they have to deal with.

Poll #5624 Support: create category for feeds
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (27.7%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support: allow users to see all their current and past requests

Area:
support

Summary:
Sometimes I know I already asked something but I've forgotten the answer I was given or I'm fuzzy on the details. I'd like to be able to find my requests (current and past) easily as I don't save Support e-mails.

Description:
I'd like to see all the requests I've filed with my current logged-in username and possibly all the requests I've filed with my any of my validated e-mail addresses.

This could be a new box on http://www.dreamwidth.org/support/:

View all my requests
-- filed with username XXX
-- filed with e-mail address XXX (selectable in a drop-down menu if there are several validated addresses?)

Poll #5602 Support: allow users to see all their current and past requests
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

Should be implemented as-is.
44 (91.7%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
4 (8.3%)

(Other: please comment)
0 (0.0%)

aedifica: Me looking down at laptop (off screen).  Short hair. (Default)
[personal profile] aedifica

Title:
Making it easier to get to Support

Area:
site navigation

Summary:
Make http://support.dreamwidth.org/ redirect to http://www.dreamwidth.org/support/ .

Description:
Currently if you go to http://support.dreamwidth.org/ you get a page telling you "There is no user support at Dreamwidth Studios." I think it'd be great if instead it automatically redirected to the Support page, http://www.dreamwidth.org/support/ .

(Besides, Dreamwidth has excellent user support, it's a lie to say there's none! *grin* )

Poll #5131 Making it easier to get to Support
Open to: Registered Users, detailed results viewable to: All, participants: 82


This suggestion:

View Answers

Should be implemented as-is.
72 (87.8%)

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

Shouldn't be implemented.
3 (3.7%)

(I have no opinion)
2 (2.4%)

(Other: please comment)
1 (1.2%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support: indicate whether an answer's been reviewed

Area:
support

Summary:
Support answers get screened until a more experienced user has reviewed and approved them. Otherwise they stay unscreened. Currently, it can be a bit difficult to know if an answer's still unscreened because it hasn't been reviewed yet or because it hasn't been approved. I think it would be useful if support admins had the possibility to mark an answer as reviewed.

Description:
Bonus points if there's a date stamp in UTC time and admins can attach a note the way community admins can when they approve or reject a submitted entry.

Poll #5119 Support: indicates whether an answer's been reviewed
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

Should be implemented as-is.
27 (60.0%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (40.0%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Create a contact page

Area:
site

Summary:
DW has no contact page. This is sad.

Description:
Sometimes 'help' doesn't seem to be what you need (even though it turns out that Support answers all kinds of questions) but you don't know where else to go. Some people might turn to Support anyway; some might just decide not to say anything for lack of direction, which is a shame in my opinion.

If the page is created, it would be nice if there was a link in the footer (+ site map of course).

Poll #5017 Create a contact page
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
43 (76.8%)

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

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
12 (21.4%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Support: new notifications

Area:
support

Summary:
You can get notified when new Support requests and new responses have been posted but not when an answer has been approved, a request closed or you've been given points. I think it's a shame.

Description:
Letting any user try to answer a request but requesting approval from more experienced volunteers before the answer is unscreened is nice. "Rewarding" volunteers with points is nice too. Not notifying someone their answer's been approved and they got some points is a bit odd, in my opinion.

Poll #4949 Support: new notifications
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

Should be implemented as-is.
42 (80.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (19.2%)

(Other: please comment)
0 (0.0%)

cesy: "Cesy" - An old-fashioned quill and ink (Default)
[personal profile] cesy

Title:
Link back to support from support notifications page

Area:
support, notifications

Summary:
Add a link back to the main support page from the "change your support notifications" page.

Description:
If you go to support and change your notifications to be notified about support requests, the success page doesn't link back to support or anywhere else - you have to hunt in the menus. Could we have a link back the the home of the support area, at least?

Poll #4644 Link back to support from support notifications page
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

Should be implemented as-is.
40 (85.1%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.6%)

(Other: please comment)
0 (0.0%)

yvi: Kaylee half-smiling, looking very pretty (Default)
[personal profile] yvi

Title:
list number of points earned on support high score

Area:
Support

Summary:
The support high score shows how many 'ranks' a volunteer has gained or lost in the last few days. It should also show how many points have been earned in that time period.

Description:
This is a very specialized suggestion :)

Support volunteers gain 'support points' based on how many questions they answer and how old these questions are. There is a high score for these points here: http://www.dreamwidth.org/support/highscores and the high score shows how many ranks someone moved up or down in a week. Dreamwidth support is not that... much in a flux, so you can better see that on the Livejournal equivalent: http://www.livejournal.com/support/highscores.bml , the red and green nubers after the usernames.

It would be really nice to additionally have a number of points earned since the last time the high score was indexed. So it would look like this:

5. chemicallace - Chemical Lace 420 points (+20)

for example.

That would satisfy my need for statistics and shameless point-grubbing and ease my pain about not moving up any further ;)

Poll #1867 list number of points earned on support high score
Open to: Registered Users, detailed results viewable to: All, participants: 27


This suggestion:

View Answers

Should be implemented as-is.
14 (51.9%)

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

Shouldn't be implemented.
2 (7.4%)

(I have no opinion)
11 (40.7%)

(Other: please comment)
0 (0.0%)

sky: (Default)
[personal profile] sky

Title:
Add a 'reason for closing/thank you' field when closing support requests

Area:
Support board

Summary:
Closing a support request currently just brings you to a page that says the request is now closed. I'd like to be able to leave a closing message.

Description:
Recently I used the support board for the first time at Dreamwidth, and (forgive me, it's been so long since I used LJ Support that I don't remember if this is the same over there) in the helpful automatic email that popped up with an answer from a volunteer, there was a "Did this answer your question? YES / NO" portion with links to click for each option. Without thinking about it I clicked on the link under 'YES', and this immediately led me to a page that said nothing except 'this support request is now closed'. I really hadn't meant to close it right away -- I wanted to thank the volunteer for their helpful answer first. It would be nice if, upon going to close a request, there was a text field provided for this purpose; aside from thanking Support volunteers, people could use it to explain the reasons for closing ('this resolved my problem', 'figured it out on my own', whatever).

Pros:
-Would be a more satisfying conclusion to the Support experience
-Would give people an opportunity to recognize volunteers' hard work with a thank you, or make the circumstances behind their closed requests more clear.

Cons:
-More text to go through might just mean more work for volunteers
-People could use the feature to flame or otherwise cause trouble


(And come to think of it, it might also be nice if it was made clearer in Support emails what each of the Yes/No links does, but I guess that's a different suggestion.)

Poll #1416 Add a 'reason for closing/thank you' field when closing support requests
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

Should be implemented as-is.
40 (95.2%)

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

Shouldn't be implemented.
1 (2.4%)

(I have no opinion)
1 (2.4%)

(Other: please comment)
0 (0.0%)

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