denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise

Title:
Discuss removing "check spelling" from quick-reply commenting form

Area:
commenting

Summary:
This suggestion is for informational purposes: we're in the first steps of redesigning the commenting form to make a bunch of things possible that would be VERY HARD right now, and we're trying to figure out which bits are utterly useful and which can safely be removed.

Description:
So, we want to add a few things to the quick-reply comment form (the inline one that shows up when you hit "comment to this entry", NOT the one that you get when you hit "more options" that's a separate page). Because it's been years since the commenting workflow has been touched -- I think the last time it got any attention was when the inline quick-reply form was first introduced and I'm pretty sure that was in like 2004 -- and we've tried to shoehorn in a few things since then, the existing inline commenting form is kind of dire.

(The big thing we're aiming at is working up some way that will let you comment as one of your other accounts without logging out of the account you're in now and having to log into that one, and allow you to specify icons other than the default, the way you can't if you use the "comment as other user" on the More Options page. But there are a few other things we could do if we did a redesign.)

Fu and I are in the very very very first stages of sketching possibilities and discussing what the revision should look like, but one of the things we're sticking on is that it's hard to add the "check spelling" option logically: it doesn't quite fit no matter where we put it, and task-wise, it's pretty isolated (it's the only thing that brings you to a separate screen other than the "More Options" button). So, I figured I would toss up this suggestion, and float the idea, and if people hate it that will tell us something. :)

The proposal, to be clear: remove the "Check spelling" checkbox from the inline commenting form, NOT from the full form that shows up when you hit "More Options", to give us room to redesign the inline commenting form in some more radical (and radically useful!) ways. At the time the inline comment form was designed, browser-based spellcheck was not as good as it is now, and people felt that having to visit the More Options page to spellcheck was really inconvenient, but these days I think it's at the point where browser-based spellcheck is so much better that I think it would be less of a concern now.

I could be entirely wrong, mind you! Hence running it by suggestions to see what people's quick gut reaction is.

Poll #11699 Discuss removing "check spelling" from quick-reply commenting form
Open to: Registered Users, detailed results viewable to: All, participants: 87


This suggestion:

View Answers

Should be implemented as-is.
66 (75.9%)

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

Shouldn't be implemented.
2 (2.3%)

(I have no opinion)
19 (21.8%)

(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!)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu

Title:
Click to show the contextual popup, instead of showing it on hover

Area:
journals, site interaction,

Summary:
The contextual popup which contains user-specific links shows up when you hover over the userhead before a username, or someone's icon. I'd like to suggest adding an extra "click" so that it only shows up when the user calls it up and can't be summoned by accident.

Description:
The contextual popup has several subtle issues, because it's triggered by hovering over something, and closed by moving your mouse off of it:

* you can trigger it accidentally by hovering over an icon or userhead while reading a comment -- the unexpected animation can be distracting, or the box might cover up content you want to read

* it fades out after a few seconds: this may be too short for people with fine motor control issues. Conversely, it may be too long for someone who has accidentally triggered the thing and just wants it to go away!

* no way to trigger it by keyboard; no way to indicate that there's anything even like this functionality to keyboard-only users



I suggest that hovering over an icon or userhead should only show a small image within the icon or userhead. This can be clicked to open the contextutual popup menu.

Pros:
* less chance of unexpected behavior and animation
* less chance of accidentally covering up the text you're reading
* more control over how you interact with the site
* it may be possible to make this keyboard friendly, by also adding the clickable trigger when someone focuses on an icon or userhead.

cons:
* adds an extra click for people who are used to the old behavior of the contextual popup showing on hover
* might not be obvious how to open the contextual popup / may not be obvious what the button does
* unexpected animation still there, just a lot subtler
* the small image overlaying the userhead will mean that you can no longer click directly on the userhead to go to that user's profile; however the link is still in the contextual popup menu (see ETA below, which may make this less of an issue)
* the small image overlaying the icon *may* make it harder to click directly on the icon to go to that user's icon page; however that link can be added to the contextual popup menu

Here's a screenshot of how it looks now, where the contextual popup shows up when you hover right over the icon.
http://afunamatata.com/dreamwidth/journal/2011/08/contextual-hover.png

Here's a quick and dirty mockup of how the extra clickable link might work:

When you hover over an icon: http://afunamatata.com/dreamwidth/journal/2011/08/icon-on-hover.png
When you click on the trigger: http://afunamatata.com/dreamwidth/journal/2011/08/icon-on-click.png

When you hover over a userhead (see ETA below for a revised version)): http://afunamatata.com/dreamwidth/journal/2011/08/userhead-on-hover.png
When you click on the trigger: http://afunamatata.com/dreamwidth/journal/2011/08/userhead-on-click.png

Mockups were made in less than ten minutes, so please assume that fiddly bits like where the trigger overlays text in the contextual popup can be fixed (and will be!)

Poll #7732 Click to show the contextual popup, instead of showing it on hover
Open to: Registered Users, detailed results viewable to: All, participants: 76


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
13 (17.1%)

Shouldn't be implemented.
25 (32.9%)

(I have no opinion)
22 (28.9%)

(Other: please comment)
6 (7.9%)



ETA 2011-08-10:

Some good points in the comments re: losing the ability to go to the profile!

Here's a modification of the hover behavior on the userheads. The trigger shows up to the left of the userhead, so the userhead remains clickable to go to the profile:
http://afunamatata.com/dreamwidth/journal/2011/08/fu-nohover.png
http://afunamatata.com/dreamwidth/journal/2011/08/fu-hover.png

foxfirefey: A fox colored like flame over an ornately framed globe (Default)
[personal profile] foxfirefey

Title:
Implement LJ's Notes feature

Area:
User interface

Summary:
Implementing LJ's new notes feature, as described here and here.

Description:
Most of this has already been implemented in the open source version of LiveJournal and a bug for adding this feature is in our bug database already; the main reason for posting this is to gather feedback on what people like and do not like about the Notes feature, so that we can adjust LiveJournal's implementation to one that best serves Dreamwidth's users.

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


This suggestion:

View Answers

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

Should be implemented with changes.
11 (25.6%)

Shouldn't be implemented.
7 (16.3%)

(Other: please comment)
0 (0.0%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom