allen: (Default)
[personal profile] allen

Title:
Quick jump to next/previous entry


Area:
reading page


Summary:
Add a javascript function to skip to the next or previous entry in your reading page. The function would be available either through a sticky element for desktop, or through a swipe gesture for mobile.


Description:
This is kind of like the Jump Links suggestion (which it looks like was accepted but lost in the bugzilla crash), but with a few differences.


The problem that it's supposed to solve is for when you end up with some long, uncut entries on your reading page (like from changelog or an RSS feed). And then you want to go to the next entry, but end up hitting page down a whole lot. Or worse, you're in mobile and you have to scroll down and keep scrolling and scrolling...


So the idea is to have a javascript function available to scroll to the next (or previous) entry in your page. This could be made available with a sticky module which would be available either in one of the sidebars or (if you don't have a sidebar) at the top of the main entry area. It would have just a 'Next' and 'Previous' button, which would take you to the next or previous entry in your reading list.


We could also include a jquery touch plugin that would add the same functionality with, say, a two-finger swipe up or down.



Edit 2017-04-24 I don't see much love for the sticky idea, but having a way to configure an optional shortcut has at least some support. So now I'm thinking a new tab in My Account Settings for Shortcuts, which would have options for

Enable keyboard shortcuts (checkbox, default unchecked)
Next (text field, default j)
Previous (text field, default k)
Enable touch shorcuts (checkbox, default unchecked)
Next (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)
Previous (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)

I could also add a way to make a link call the JS function so that anyone who wanted to use links instead of key bindings or touch gestures could just include those in their styles.

Poll #18201 Quick jump to next/previous entry
Open to: Registered Users, detailed results viewable to: All, participants: 26


This suggestion:

View Answers

Should be implemented as-is.
5 (19.2%)

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

Shouldn't be implemented.
10 (38.5%)

(I have no opinion)
5 (19.2%)

(Other: please comment)
2 (7.7%)

kerravonsen: (Default)
[personal profile] kerravonsen

Title:
Take image descriptions from the image meta-data

Area:
image hosting

Summary:
Save time in creating image descriptions by taking them from the image meta-data, using that to pre-fill the image description form.

Description:
When one uploads an image to the DW image hosting (yay!) you are able to drag-and-drop or select an image to upload, and then you get presented with a form which has things like "Title" and "Description" in it, which you have to fill in. But a lot of my images already have descriptions in the meta-data (e.g. the "Comment" field in a JPEG file). It's a pain to have to type all of that in again when I already did it once. What I would like to suggest is that the image uploader read the meta-data from the image, and use that to pre-fill the form. The user then can edit that as they like, but if they're already happy with what's in their meta-data, they can just save what's there without changing it. This would also be useful if someone is using the old "upload by email" interface which used to be the only way of uploading images to DW. That interface could use the meta-data of the image to fill in the Title and Description information, which the user could edit later on the DW website. As for what meta-data to use, I think one could use the filename for the Title (that's what LJ does) and use the JPEG "Comment" field, or the "Caption-Abstract" field from the EXIF data for the Description.

Poll #18047 Take image descriptions from the image meta-data
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

Should be implemented as-is.
16 (50.0%)

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

Shouldn't be implemented.
6 (18.8%)

(I have no opinion)
5 (15.6%)

(Other: please comment)
1 (3.1%)

toudaimori: (Default)
[personal profile] toudaimori

Title:
(Read more...) functioning as the black triangle to the left of it

Area:
Cut

Summary:
Can we please have the (Read more...) link functioning as the cut-opening arrow, not as the direct link to the entry?

Description:
Right now, when you click the (Read more...) link, you are redirected to the whole entry with the comments. If you want to simply open the cut and read what's inside, remaining on the main page of the journal, you have to click the tiny black triangle to the left of (Read more...). Can we please ditch this black triangle, which is barely visible, and have the (Read more...) link functioning as one? As for the direct link to the whole entry, it can be moved to the header, which is currently plain text without any use.

Poll #18025 (Read more...) functioning as the black triangle to the left of it
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

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

Shouldn't be implemented.
25 (55.6%)

(I have no opinion)
5 (11.1%)

(Other: please comment)
1 (2.2%)

blackorange: (Default)
[personal profile] blackorange

Title:
posting a comment

Area:
comments

Summary:
is it possible to implement a worldwide hotkey ctrl+enter for posting a comment?

Description:
is it possible to implement a worldwide hotkey "ctrl+enter" for posting a comment?

Poll #18024 posting a comment
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
2 (5.9%)

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

Shouldn't be implemented.
8 (23.5%)

(I have no opinion)
20 (58.8%)

(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 Entries beta : help button for HTML and Markdown

Area:
entries

Summary:
I suggest adding a help button (i) or link to help us with editing. If you have forgotten which HTML tags are allowed or how to write something in Markdown, you're currently out of luck on the beta page. There is not 'help with editing' link anywhere. I think it would be nice to have one (or two; one for HTML and one for Markdown).

Description:
A help panel we could switch to and from from without leaving the page would be awesome but links to the following in new tabs/windows would be great too:

http://www.dreamwidth.org/support/faqbrowse?faqid=82 (What Dreamwidth-specific markup/HTML tags can I use?)

http://www.dreamwidth.org/support/faqbrowse?faqid=260 (How can I use Markdown to format my entries?)

http://daringfireball.net/projects/markdown/syntax (Markdown formatting and syntax)

http://www.dreamwidth.org/support/faqbrowse?faqid=103 (What HTML can I use in my entry?)

Poll #18017 Create Entries beta : help button for HTML and Markdown
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

Should be implemented as-is.
32 (80.0%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (20.0%)

(Other: please comment)
0 (0.0%)

zaluzianskya: (Default)
[personal profile] zaluzianskya

Title:
Allow linking to parent comment with only one child thread

Area:
Comments

Summary:
I guess this would be sort of like reddit's context links: A way to view a comment's parent comment, but without any other children of that parent.

Description:
Sometimes I want to link to a specific comment or thread, but there's important context in that comment's parent. However, the parent comment might already have tons of other children. Especially when those other children are above the one I'm linking to, that's really inconvenient for the person I'm sending the link to!

Some way to show just the comment I want along with the parent comment would be a godsend. Preferably with some way to indicate that this isn't the entire thread (possibly with some kind of [click here to see X number of other comments] link, or some other indication).

Poll #18012 Allow linking to parent comment with only one child thread
Open to: Registered Users, detailed results viewable to: All, participants: 33


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (9.1%)

(I have no opinion)
11 (33.3%)

(Other: please comment)
1 (3.0%)

alucinari: A woman of Asian heritage with white hair, staring at the viewer with a stern expression and hair blowing in the wind. (Default)
[personal profile] alucinari

Title:
Icon description length.

Area:
Icon descriptions.

Summary:
Increasing the length of the icon description.

Description:
Hello! I have friends that use screen readers, and a problem I have found is that when I am trying to describe icons, especially if it's a text icon with a longer quote on it, there's not enough room for me to properly describe what's going on; I either have to leave a lackluster description, or resort to chat speak, and sometimes even that doesn't really do the trick. It would be really helpful if DreamWidth allowed longer icon descriptions! It should be easy to allow more characters, and there shouldn't be any drawbacks, I don't think? Thank you for your consideration.

Poll #16838 Icon description length.
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
26 (60.5%)

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

Shouldn't be implemented.
2 (4.7%)

(I have no opinion)
15 (34.9%)

(Other: please comment)
0 (0.0%)

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

Title:
Make Sidebar and Tags Page Tag Counts Into Links

Area:
tags, styles

Summary:
On other websites (in all truth, I can't remember exactly which ones) I've seen tag counts (such as "News: 20 uses", for example) displayed as links. By clicking the number 20 in my example - or the whole line, "20 uses", depending on how exactly the usage count is worded/displayed - one is taken to a page that shows all uses of that tag, exactly the way clicking on the tag *name* itself works right now on DW. I would like to 1) see the tag count included in the tag name link, for both styling and accessibility purposes or b) make another link for the tag count itself.

Description:
Right now tag counts don't have their own CSS classes or any fine-grained styling options in the Customize Style interface (but these first two issues are initially covered in another suggestion I've recently made), nor do they display as links. On my own DW I often look at the tag counts, in the sidebar in particular, and wonder why they can't also possibly function as links. It seems intuitive that you might read a user's tag names, check the tag counts on each one, then might want to, for example, click through based on a particularly high or low number of uses on at least one or more of those tags. But the ability to click through on a tag count isn't there so as a mouse user, for example, you might have to swing your mouse back across the screen to click on the tag name instead. This could sort of be a hassle, especially if there's more than one tag you want to click through on. My solution is to simply linkify the tag counts.

Poll #14589 Make Sidebar and Tags Page Tag Counts Into Links
Open to: Registered Users, detailed results viewable to: All, participants: 27


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (18.5%)

(I have no opinion)
12 (44.4%)

(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:
Handling alt text with emailed images

Area:
entries, images, post by email, accessibility

Summary:
Development (mostly Mark & Fu) intend to improve the workflow of posting images, and I'm the one tagged to post this bit for suggestions discussion. :) Specific to this discussion: adding alt text to a single image that is attached to an emailed entry. We call upon the collective creativity of the dw_suggestions community: how should it work?

Description:
The existing post-by-email optional/extra/advanced features are documented:

http://www.dreamwidth.org/manage/emailpost?mode=help&type=optional
http://www.dreamwidth.org/manage/emailpost?mode=help&type=headers

Should the alt text take the form of another "post" command at the top, like one of these two:

post-alt: image's alt text goes here
post-image: image's alt text goes here

Should it be done another way? If so, how?

Poll #13462 Handling alt text with emailed images
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
22 (71.0%)

(Other: please comment)
0 (0.0%)

oyceter: teruterubouzu default icon (Default)
[personal profile] oyceter

Title:
Change "Expand" alt text on cut tag icon to "Collapse"

Area:
accessibility, images

Summary:
Change the alt text on the right-pointing arrow on a cut tag from "Expand" to "Collapse" once the user has clicked on the tag or arrow and expanded the cut tag.

Description:
I browse the site with images off, and sometimes I get confused if I've expanded a cut tag or not because the alt text for the cut tag icon reads "Expand" no matter what state the cut tag is in. If the alt text is changed to "Collapse" when the cut tag is expanded, it will hopefully improve accessibility for people who browse the site without images.

Possible drawbacks: I'm not actually sure how this would work in a screenreader.

Poll #13125 Change "Expand" alt text on cut tag icon to "Collapse"
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (21.8%)

(Other: please comment)
2 (3.6%)

metawidget: A platypus looking pensive. (Default)
[personal profile] metawidget

Title:
Somewhat confusing message confirmation page title

Area:
Messaging

Summary:
The title of the page confirming that a message has been sent is "Compose Message", which when I see a tab with that, makes me think I have unfinished message business. Maybe, if the page (http://www.dreamwidth.org/inbox/compose) is confirming a sent message, the page title and header could read "Message Sent Successfully" or something similar.

Description:
This would make the site more usable for heavy tab-flipping types, and I suspect for people who get their pages in a very linear manner, e.g. screen-reader users or people using very large type — they would know immediately what has happened with their message right away.

Ideally, if the message failed to send for some reason, the title and heading could indicate that too — I've never had a message fail to send, but while you're in there, it might be nice to change that.

I suspect the solution wouldn't make anyone's life harder — it'd be another few entries in the English-stripping file and some more logic in building the page, but from the user perspective I can't think of a drawback, so long as the new titles all included the word "message" to cue people as to what process is succeeding or failing.

Poll #12203 Somewhat confusing message confirmation page title
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
46 (80.7%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (19.3%)

(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:
Sitewide antispam capability: comment CAPTCHAs for inactive accounts

Area:
comments, anonymous users, inactive users, antispam

Summary:
When an account becomes inactive (discussion of what constitutes "inactive" for the purposes of this concept to follow), require any anonymous comments to fill out a CAPTCHA. If/when the account becomes active again, revert to the user's settings. This would not delete anything already in the journal, would not stop logged-in users from commenting, and would allow anonymous users who could solve the CAPTCHA to comment.

Description:
Spun off the comments on http://dw-suggestions.dreamwidth.org/1374810.html --

Spam comments are a woe that should be discouraged, while not discouraging comments of legitimate discourse from real sentient beings.

Most comment spam on Dreamwidth is anonymous. One of the places that spammers strike is the accounts of people who have become inactive. If someone's not around for any particular reason, they generally can't get rid of any spam that shows up in their journal. Emboldened by the way their first overtures have not been repelled or cleaned up, the spammer strikes again, and again, and again.

Anonymous spam is present until cleaned up by the journal owner (or someone logged in as them). Registered user/OpenID spam is only present until someone (someone else hit by the spammer, or a good neighbor) reports the spammer and the spammer is suspended; all of the spam comments left by that user will then go away across the site.

For this reason, it is more important to attempt to repel anonymous spam in the event that the journal owner is not around and therefore not able to take action.

When the journal owner becomes inactive, and the journal allows anonymous comments, and the journal owner does not already present anonymous comments with a CAPTCHA, and anonymous comments are not screened by default (screening leaves the anonymous comments invisible to search engines unless the journal owner comes through and unscreens them, and by that time first the owner is active, and second, the owner is hardly going to unscreen spam on purpose unless there's a bigger problem) then there should be a sitewide setting to put up a CAPTCHA upon the attempted anonymous comments to those journals.

Now the definition of "inactive" for the purposes of probably not actively gardening journal comments. This should be something that can be adjusted on the administrative end of things should it not be got right on the first try. As a first attempt:

No new or edited entries in personal journal
No new or edited community entries? (Can we track this?)
No new or edited comments (from the journal, not to the journal, either in their own journal or abroad) (can we track this?)
No active login sessions

... for at least 60 days? Doing anything that touches one of the above things would start the clock over again. If someone logs in, leaves a comment in a community, deletes the comment, and logs out, that would restart the clock. If someone leaves themselves logged in after doing that, they would have until that login automatically expires before the clock starts.

Poll #11570 Sitewide antispam capability: comment CAPTCHAs for inactive accounts
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

Should be implemented as-is.
39 (72.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (13.0%)

(Other: please comment)
0 (0.0%)

ladyasul: A picture of the back of a fairy, with their red-and-gold wings spread out. (Default)
[personal profile] ladyasul

Title:
Long ECHI could stand to get broken up

Area:
comments, comment display

Summary:
When the ECHI (Explicit Comment Hierarchy Indicator) gets very, very long, like in a 100+ comment-deep thread, it can do odd and ugly things to the layout. Perhaps it could be broken up with spaces, every so many levels, to avoid mauling page formatting and allow it to wrap and improve ease of reading/understanding?

Description:
On comment pages, when a thread of comments gets very long (as often happens in some conversations, but mostly happens in roleplay threads, in my experience) the ECHI (Explicit Comment Hierarchy Indicator) can get VERY long. As in, absolutely ridiculous. It stretches comment headers and collapsed comments alike, and tends to make the layouts I've tried, including the site-schemed pages, behave poorly because of it.

Plus, after a while, it simply seems to blur into one long trail of characters, to try to read it. Phone numbers are broken up into groups of usually 3 and 4 digits for readability (and ease of remembering.) It would be great if the ECHI output could be broken up as well (by spaces every so many characters?) so that it could be made more human-readable and wrap within comment headers, too.

For example, one actual ECHI from an RP thread I was trying to read is 326 characters long (counting the period at the end.) It would be far nicer if it could be displayed more like this instead:


86a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a.


My default font size is fairly normal (14-15px) so I can only imagine how badly the page layouts would break for someone who has their font sizes set much higher for eyesight reasons.

I've tried mucking about with Stylish to make the comments' headers and the collapsed comments simply scroll sideways when this happened, but couldn't find CSS which would do this to my satisfaction and still let the comments stretch horizontally with the page how I wanted them to.

As it is, I switched accounts just so I could read that thread without scrolling horizontally to read each comment's text.

I'm not sure what drawbacks such a fix would have. Maybe there would be disagreements over where to add the spaces so that the ECHI can be wrapped, or it would be difficult to implement? I know that long ECHI strings aren't an issue for most people, but it would be nice for something like this to be implemented for those times where it does become an issue.

Poll #11554 Long ECHI could stand to get broken up
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
29 (67.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (30.2%)

(Other: please comment)
1 (2.3%)

[personal profile] septim

Title:
Allow users to pick with type of CAPTCHA test they see

Area:
comments, entries

Summary:
Allowing users to choose which type of CAPTCHA (text-based or graphic based) they will see/take through Manage Account.

Description:
Users choosing what type of CAPTCHA they will see/take allows greater accessibility.

I have dyscalculia and the text-based CAPTCHAs are full of arithmetic problems, thus I keep failing them. As of now, there's no way to choose which CAPTCHAs you will take, only what type of CAPTCHAs others will see in your journal.

Poll #10625 Allow users to pick with type of CAPTCHA test they see
Open to: Registered Users, detailed results viewable to: All, participants: 78


This suggestion:

View Answers

Should be implemented as-is.
56 (71.8%)

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

Shouldn't be implemented.
3 (3.8%)

(I have no opinion)
17 (21.8%)

(Other: please comment)
1 (1.3%)

ceesoo: (Default)
[personal profile] ceesoo

Title:
Add the Display Name to the comment header

Area:
comment pages

Summary:
There's been a lot of debate over using the username vs. the display name on icons' alt-text+hover-over tool-tip and the accessibility/usability issues that come with changing it from username to display name. This solution is a good compromise on the issue, since it puts the display name somewhere accessible to everyone: after the username in the comment header.

ETA: Also check out the comments for other ideas for implementation not covered by the suggestion. Here's the most promising one.
ALSO also, as a warning: having a display name somewhere useable is a topic people have strong feelings on. Try to be considerate in the discussions, whatever implementation you do or don't support.

ETA 2: A list of solutions proposed so far including some pros and cons of each. If you'd still like to vote, click "implement as-is" for the idea in the description below, and click "implement with changes" if you like something else on the list and comment to the main post to say which (or to the comment linked above if you like the inline reply idea).

Description:

I'd like the Comment Headers to show a user's chosen display name next to their username.

SOME BACKGROUND INFO ABOUT PAST SUGGESTIONS AND ITS ACCESSIBILITY )


It'd be better to use something like this!

=====HOW VISUAL BROWSERS WILL SEE IT=====
http://i224.photobucket.com/albums/dd290/ceesoo/SabraLaTau/layouts/displayname02.png
with the hover-over tool-tip reading "username: Keywords which may also be fairly lengthy (Description of the icon which can be fairly lengthy)"

=====HOW SCREENREADERS WILL SEE IT=====
[Icon] usernameis25charactersmax: Description of the icon which can be fairly lengthy (Keywords which may also be fairly lengthy)
And then it reads the subject if you put one.
[Userhead] [Personal Profile] usernameis25charactersmax (This is a display name that is 50 characters long.)
date-time etc.
---------------------------------------
This way, if they don't want to hear the username over and over I imagine it's easier to skip one word than a long name or phrase, but they can also get at the display name easily just like visual users can by skipping down to the username and display name line. Meanwhile, people on mobile devices or who just can't use hover-over for whatever reason are also able to see the display name because it doesn't require any hovering.

In terms of visual space in the comment header, I don't think 50 characters is too many, as a maximum. And anything that a user didn't fill out would simply not show up. If a user doesn't designate a display name, it'd be best not to show anything in the comment header.



TERMS
* alt-text: what screen readers hear when reading past an icon
** tool-tip/title text: that thing that shows visual users our keywords. DW has it set to contain the same info as the alt-text except in a different order, in an effort to ensure all users have an equivalent experience using the site.

SOME CONNECTED DISCUSSIONS
1) http://dw-accessibility.dreamwidth.org/18357.html
2) http://dw-suggestions.dreamwidth.org/609311.html
3) http://dw-maintenance.dreamwidth.org/44980.html?thread=1361844#cmt1361844
4) http://dw-news.dreamwidth.org/32824.html?thread=4544056#cmt4544056



Poll #9974 Add the Display Name to the comment header
Open to: Registered Users, detailed results viewable to: All, participants: 129


This suggestion:

View Answers

Should be implemented as-is.
76 (58.9%)

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

Shouldn't be implemented.
17 (13.2%)

(I have no opinion)
20 (15.5%)

(Other: please comment)
2 (1.6%)

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

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

Title:
Icons: rename 'comment' to something else such as 'notes' or 'info'

Area:
icons

Summary:
People use the 'comment' field in very different ways: to give credit to the icon maker, provide additional keywords, categories or information, mention whether it's shareable or even don't use it at all. It seems to me the word 'comment' doesn't really fit any of these uses. Something like 'notes' or 'info' would fit better and may help distinguish this field from the description one.

Note: edited to add better suggestions.

Description:
Ideas welcome!

Poll #9953 Icons: rename 'comment' to something else
Open to: Registered Users, detailed results viewable to: All, participants: 62


This suggestion:

View Answers

Should be implemented as-is.
16 (25.8%)

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

Shouldn't be implemented.
13 (21.0%)

(I have no opinion)
26 (41.9%)

(Other: please comment)
2 (3.2%)

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

Title:
Mobile Reading page: add previous/link at the bottom too

Area:
reading page, mobile

Summary:
On http://www.dreamwidth.org/mobile/read, add a link to view previous/next entries at the bottom.

Description:
This would let you see past entries without having to go back to the top of the page.

Poll #9858 Mobile Reading page: add previous/link at the bottom too
Open to: Registered Users, detailed results viewable to: All, participants: 65


This suggestion:

View Answers

Should be implemented as-is.
58 (89.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (10.8%)

(Other: please comment)
0 (0.0%)

momijizukamori: Green icon with white text - 'I do believe in phosphorylation! I do!' with a string of DNA basepairs on the bottom (Default)
[personal profile] momijizukamori

Title:
Add 'Jump Links' to Recent Entries and Reading Circle pages to make skipping between entries fast

Area:
Reading pages

Summary:
Add links to the next and previous entry to each entry on the recent entries and reading circle pages, allowing users to quickly skip between entries

Description:
So <user name="exor674"> coded a neat little custom S2 thing, which is probably most easily explained by linking to her recent entries page - http://exor674.dreamwidth.org/?style=original The '<|>' right underneath the subjects are links that take you to the subject line of the previous/next post of the page, respectively. I thought this was so cool that I offered to write it up as a suggestion, for inclusion as an option in the core2 default page *g*

It's particularly handy for situations where scrolling a lot is hard or irritating - on a phone, for instance, or for skipping several long entries that you've already read (or don't want to read, for whatever reason) quickly, rather than having to scroll past them. And while her code would need a little bit of clean-up for core2 inclusion, the basic functionality has already been written. I would suggest this as an 'opt-in' option, probably, in the Customize menu.

Poll #9853 Add 'Jump Links' to Recent Entries and Reading Circle pages to make skipping between entries fast
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

Should be implemented as-is.
29 (52.7%)

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

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
19 (34.5%)

(Other: please comment)
1 (1.8%)

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

Title:
Make the cuttag arrows scalable.

Area:
Entries

Summary:
This is a very small suggestion about some very small things--the cuttag arrow images. They are small in size on the screen--11-15 pixels a side. Small in file size--around 100 bytes. And small in target--the image link has no padding on it.

They should be bigger and scalable.

Description:
Make the images scalable.

It's easy to make the arrow images scale up with a user's font size. You just need to set a width on the image in ems--something like .7em, which at a 16px font would show the arrow the same size it is now, but would let the image get bigger as the font size went up.

The problem is that the images are so low resolution, even very minor enlargement makes them very blurry. Making the images much higher resolution to begin with means that they start out shrunk down and they have room to grow.

Users of touch screens that zoom on the arrows to make them big enough for a finger to hit will also benefit from a less blurry image.

This increases the file size of the image. I made an 88 pixel square .gif of the right-facing arrow and it went from 91bytes to 573bytes. Something more in the 44px range is likely adequate if file size is a concern--that would give a clean image at up to a 62px font size.

Make the target bigger for everyone.

"Target" refers to the area you have to hit with your cursor or your finger to click a link. Right now it is the size of the image, nothing more.

I use a padding of 0.2em on the image and it gives me an 18px square to hit at default font size, instead of an 11px square. It makes a huge difference. (By the way, the span class .cuttag is inconsistently applied in the code and doesn't appear on the closing collapse arrow.)

Making the image scalable and putting some padding on it would make it a feature more users can enjoy.

Poll #9802 Make the cuttag arrows scalable.
Open to: Registered Users, detailed results viewable to: All, participants: 73


This suggestion:

View Answers

Should be implemented as-is.
56 (76.7%)

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

Shouldn't be implemented.
2 (2.7%)

(I have no opinion)
15 (20.5%)

(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