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

peoppenheimer: A photo of Paul Oppenheimer at the Australasian Association of Philosophy meeting. (Default)
[personal profile] peoppenheimer

Title:
Support MathJax in Entries

Area:
MathJax JavaScript support at site level

Summary:
I suggest that (in due time!) dw support MathJax <a href="http://www.mathjax.org/">MathJax</a> for mathematical/technical formatting in dw entries.

Description:
This suggestion is intended to make it easy for dw people to write beautiful and useful mathematical/technical content in our entries. MathJax is now a mature and well-supported FOSS extension of html via javascript, with healthy user and developer communities. We've been experimenting with MathJax for the Stanford Encyclopedia of Philosophy, and we've been very pleased with it so far. (This is not an official SEP endorsement.) Code can be written or displayed rendered or in TeX or MathML. This makes it useful also for gacking and modifying, and even for learning more about those markup languages. Anyone who has tried to do serious mathematical or technical typesetting in html will agree, I think, that html is *not* a typesetting language. MathJax goes a long way toward allowing decent technical typesetting in an html context.

If MathJax can be permitted as a tightly controlled JavaScript layer at the dw site level, which I think it can, then users will be able to write mathematical and technical fragments into their journal entries as easily as any other html. I don't envision putting MathJax support into the rich text editor -- I anticipate that anyone who wants to use MathJax will be comfortable editing their own markup. This is rather an extension of html markup into a wider domain.

It is possible that I'm overestimating the ease of implementing this suggestion, but I've experimented with MathJax support in my personal webpages and at the SEP site, and it looks as though MathJax makes this as easy as possible. Furthermore, the social/political aspects look promising, insofar as the MathJax user and developer communities look like just the sorts of folks dw wants to make alliance with, as far as I can tell.

Poll #12341 Support MathJax in Entries
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.4%)

(I have no opinion)
26 (55.3%)

(Other: please comment)
2 (4.3%)

gerald_duck: (Default)
[personal profile] gerald_duck

Title:
I want the date format "Sat 2012-12-01" (or custom date formats)

Area:
Internationalisation/time and date

Summary:
I always use ISO format dates, so definitely want my journal displayed using those. However, in the context of a blog it's also useful to know on what day of the week a posting or comment was made, so it would be nice to have day-of-week followed by ISO date.

Description:
As per the title, and for the reasons in the summary, I would specifically like the date format "Sat 2012-12-01".

However, I have no idea how many other people would like that specific format. Maybe it would be good instead to provide a mechanism for users to specify custom date and time formats?

There are already existing standards for this, such as the trusty old POSIX strftime ( http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html ), ICU format strings ( http://userguide.icu-project.org/formatparse/datetime#TOC-Date-Time-Format-Syntax ) or the Microsoft one familiar to users of Windows and/or Excel ( http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx ).

It would be good to use one of those rather than reinventing the wheel. My vote would be for ICU, provided that library is available to the DW platform.

Poll #12340 I want the date format "Sat 2012-12-01" (or custom date formats)
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.5%)

(I have no opinion)
21 (47.7%)

(Other: please comment)
1 (2.3%)

[personal profile] chagrined

Title:
Remove unnecessary whitespace from embedded objects

Area:
Entries

Summary:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries to avoid problems with nesting iframes. I want to remove that extra whitespace by fixing the iframe style instead so that the nesting does not cause problems. This will give users more control over entry flow/layout.

Description:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries. I assume this was done because if a user embeds an iframe object in an entry, the Dreamwidth code puts that iframe inside another iframe, and then if the two iframes are the same size, you get scroll bars because the body tag in the outer iframe has a margin of 8px around it (in my browser; other browsers may add other margin sizes). Thus, someone wrote some code to add an extra 50px to the width and height of the outer iframe object.

Unfortunately, this leads to an extra 42px of whitespace below the embedded object (in addition to the 8px of whitespace above and to the left and right). Visually this looks like a bunch of extra line breaks under an embedded object, and makes it frustrating when one is, for example, trying to add text after that object (as an explanation/comment, etc.), because it will show up several lines below. It makes it harder for users to control the visual layout of their own entry because there is no way to get rid of this unnecessary whitespace.

My solution is a patch I have already successfully tested out on my Dreamhack account. It will remove the extra 50 pixels of blank space. Instead, the outer iframe's body tag will be given a style with a margin/padding/border of 0. Then both iframes can have the same height/width. There won't be problems with scrollbars and there won't be lots of unneeded whitespace. As with an image or anything else that can be inserted in a Dreamwidth entry, users will be able to control how much space they want around embedded objects.

Poll #12194 Remove unnecessary whitespace from embedded objects
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (37.5%)

(Other: please comment)
0 (0.0%)

blue_rampion: A blue rose in the rain (Default)
[personal profile] blue_rampion

Title:
Change date format in site-styled entries

Area:
entries, site

Summary:
Instead of displaying the date in site-styled entires numerically, the month should be displayed as the name of the month.

Description:
Currently, all dates on site-styled entries are displayed numerically in the year-month-day order. But not everyone in the world is used to that order, so this can cause confusion for readers used to differently-ordered dates - particularly when the day is 12 or under. I'm used to dates being written with the day before the month, and I'm always having to stop and think about dates when I'm reading and remind myself that a date like 2012-07-03 is actually July and not March.

I suggest that dates instead be written with the name of the month in text, because regardless of what order you are used to for dates there's no chance for confusion.

Other solutions could include allowing users to set the order for all dates in their account settings. The benefit here is that everyone could have dates set up exactly how there are used to. But, I would imagine that this would be more difficult to implement and could increase decision fatigue.

Poll #11029 Change date format in site-styled entries
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

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

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

Shouldn't be implemented.
12 (24.0%)

(I have no opinion)
6 (12.0%)

(Other: please comment)
1 (2.0%)

vickyblueeyez: (Default)
[personal profile] vickyblueeyez

Title:
Latest page tweeks and filters

Area:
styles

Summary:
I'd like to suggest some latest page tweeks like the option for 'image placeholder', filter and showing user icons.

Description:
I love browsing the Latest page on DW. Sometimes you get loads of images due to RP journals, photography journals and so on. I'd like to be able to view the Latest page with 'image and video placeholders' similar to how I can view my friend's list on my ipad if I'm reading another journal site via their app.

Also I would love to be able to see user icons on the side of the posts. You could accomplish this by maybe making Latest available to view in friend's view or your style somehow. I don't really know.

In addition, being able to not see NSFW journal public entries on the Latest would be great. Having to opt in or out would be fine. Some kind of Latest filter would work.

A language filter would be great too so non English speakers can only see Latest in their language if they desire and vice versa.

DW Latest so far is spam free and nsfw porn image free which is why I read that one more vs LJs.

Poll #11026 Latest page tweeks and filters
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
12 (28.6%)

Shouldn't be implemented.
3 (7.1%)

(I have no opinion)
18 (42.9%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Art & Text: heart with aroace colors, "you are loved" (Default)
[personal profile] ninetydegrees

Title:
Site-styled entries: remove 'UTC' or only display it when it's really UTC

Area:
entries, site

Summary:
Time in site-styled entries displays like so: @ 2012-06-21 22:51 UTC or @ 2012-06-21 10:51 pm UTC but, unless I'm mistaken, it uses your time (i.e. the time on your computer clock when you posted the entry) and doesn't convert it to UTC (or at least not all the time). I think it's confusing and should either display when it really is UTC or not display at all.

Description:
Tried this logged in and logged out, whether I had set a time zone or not and still got *my* time.

Poll #11024 Site-styled entries: remove 'UTC' or only display it when it's really UTC
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
3 (5.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (3.5%)

(Other: please comment)
0 (0.0%)

zellieh: kitten looking shocked, openmouthed, text: WTF? (What the fuck?) (Default)
[personal profile] zellieh

Title:
After commenting, return to previous comment-thread settings in entry

Area:
comments, entries

Summary:
After I leave a comment, I am returned to an entry page set to the default Threaded view for comments. I'd like it if the commenting process could magically remember if I was viewing the entry with all comments Expanded or in Flat view before I commented, and return me to the entry page set to whatever setting I'd picked.

Description:
So, Fandom_Secrets came to DW (Yay!), and I noticed a minor irritation I've had on DW before:

When I 'Expand All' (or 'Flat') comments on a post with lots of comments, then reply to one of those comments, after I hit 'Post', my comment appears on an entry page that's been set back to the default Threaded comments setting, with some comments hidden again.

Which means I have to go back and hit 'Expand All' (or 'Flat') again before I can continue reading and commenting. This disrupts my chain of thought, and in a big post where I'd like to comment to a lot of conversations and sub-discussions, it can get annoying after a while.

If the comment page could magically notice & remember to return me to the entry page/comment thread set-up I'd picked, that would save me several seconds that I could use to invent cheap, workable cold fusion and/or waste on watching Youtube kitten videos. More seriously, it could help some people with accessibility issues navigate pages more easily.

How could this be done? Well, elves would have to use some elven magic, obviously. Very magical creatures, elves. ::nods seriously::

Potential problems with page load, server load, etc? Ask the elves. I'm not really an expert on magic, elven or otherwise. I'd be willing to offer chocolate biscuits and milk, if that helps, but I think that might be for brownies...

Poll #11019 After commenting, return to previous comment-thread settings in entry
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
48 (85.7%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (14.3%)

(Other: please comment)
0 (0.0%)

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

ninetydegrees: Art & Text: heart with aroace colors, "you are loved" (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%)

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

little_terror: (Default)
[personal profile] little_terror

Title:
Fluid width content on entry pages

Area:
styles, entries, usability

Summary:
Fluid width content on entry pages to improve usability and readability.

Description:
At the moment, DW only seems to provide fixed content on default/unstyled entry pages. Because of the fixed content parameters, overwhelming whitespace can be an issue for larger monitors and computers running higher resolutions. Moreover, long comment threads end up "shrinking" very quickly, necessitating users to click more links (such as thread or expand) in order to view content.

Fluid width for entry pages would decrease the amount of uncomfortable whitespace users running higher resolutions encounter. Fluid width would also prevent long comment threads from shrinking too quickly and decrease the amount of clicking users are required to do at present.

Implementation of fluid width should not be difficult, as the style sheet that currently powers the default entry style only needs to have fluid width coded into style containers.

In conclusion, fluid width would improve usability and readability across platform and resolution. I hope the DW development team considers this suggestion!

Poll #9492 Fluid width content on entry pages
Open to: Registered Users, detailed results viewable to: All, participants: 51


This suggestion:

View Answers

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

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

Shouldn't be implemented.
20 (39.2%)

(I have no opinion)
13 (25.5%)

(Other: please comment)
3 (5.9%)

sophie: A cartoon-like representation of a girl standing on a hill, with brown hair, blue eyes, a flowery top, and blue skirt. ☀ (Default)
[personal profile] sophie

Title:
Allow permalinks to comments with added context

Area:
Commenting

Summary:
When linking to a comment, there are currently two ways of doing it - either linking directly to the comment itself, or linking to a parent or grandparent. The latter approach has problems though because it also shows other sibling comments which may not be relevant. I propose adding a new mode which shows the linked comment and several parent comments, with no siblings.

Description:
Right now, it's impossible to link to a particular comment with context without including other sibling comments in the output too, and if the comment you want to link to is further down the page, it's not easy to point attention to that comment specifically.

As well as being a Dreamwidth user, I'm also a user of Reddit, which also has threaded commenting. The way they solve this is by allowing the display of a number of levels above the linked comment, and highlighting the linked comment in particular. For example, http://www.reddit.com/r/IAmA/comments/p6gza/im_dr_norman_rosenthal_psychiatrist_author_and/c3mwork?context=3 links to a comment of mine (Sophira) with two levels of parent comments, without any siblings. (The link would normally specify three levels, but as it happens there aren't three levels above mine.)

Reddit's implementation doesn't look accessible - it only distinguishes the linked comment by colour, and with a very subtle shade at that - so if we implemented this it would be necessary to make it more accessible, both by added text and by a more obvious shade of colour.

One problem with this is that I'm not sure how easy it would be to incorporate this into existing styles. It would be nice to try, though.

(Edit: In the comments, I've posted an example showing exactly what I mean.)


Poll #9489 Allow permalinks to comments with added context
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (9.3%)

(I have no opinion)
26 (60.5%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Art & Text: heart with aroace colors, "you are loved" (Default)
[personal profile] ninetydegrees

Title:
Inbox: Make it clearer that the 'Sent' folder is part of 'All'

Area:
notifications, inbox

Summary:
Because 'Sent' is visually separated from 'All', I always forget that when I'm in the All folder clicking on 'Delete All' will also delete messages in Sent unless I flagged them. I would like a way to make it clearer that 'All' really is all, including 'Sent', especially since sent messages aren't displayed there so I find it very easy to forget about them.

Description:
Making the indents bigger might work or removing the '---'separation and making it smaller or different.

Edit: other ideas: moving Sent above Flagged and/or above Unread; setting Sent apart; adding a count to Sent (I think this would help a lot).

Thoughts?

Poll #9059 Inbox: Make it clearer that the 'Sent' folder is part of 'All'
Open to: Registered Users, detailed results viewable to: All, participants: 62


This suggestion:

View Answers

Should be implemented as-is.
45 (72.6%)

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
15 (24.2%)

(Other: please comment)
1 (1.6%)

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:
Increased font size on Tropospherical site scheme

Area:
Site scheme (Tropospherical)

Summary:
At the moment, Tropo shows entry and comment text at 75% of browser default. This winds up being a bit on the small side, compared to other similar websites, which leads to squinting and headaches after lots of site-schemed page reading for people who don't usually experience these problems, particularly as Tropo Red is the 'default' people who are new to the site see. Increasing this a bit (I would suggest 0.85em) would increase readability

Description:
This came about as a result of some of the LJ-migration recently, where a number of people who are not usually photosensitive mentioned getting headaches after browsing on both Tropo Red and Tropo Purple for a while. I did some poking about in CSS, and discovered that the 0.75em size scales text down to a bit smaller than the size I usually see on blogs or LJ's old site schemes. It's basically in that range of 'just enough change to cause problems, not enough change to be immediately noticeable'.

I wrote a quick Stylish script to increase font size to 0.82em (along with a slightly smaller line height, but I think it's the font-size that's the core issue) and got feedback that yes, it was a lot more readable that way. 0.82em is kind of weird, and I'd probably just say round up 0.85em to be neat about it.

The problem with writing it as a Stylish script, though, is that any time someone is not at their home computer, it's back to site default (and I do realize that there are other site schemes, but most people I've talked to don't like the horizontal navigation of Celerity and find black-background even harder to read). Increasing the font-size just a bit should be a fairly easy fix (unless it's not in CSS styling? I haven't had a chance to poke through files), and it's not a big enough change to negatively affect users who didn't have the problem with the smaller font size while helping people who do.

Poll #9005 Increased font size on Tropospherical site scheme
Open to: Registered Users, detailed results viewable to: All, participants: 81


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (9.9%)

(I have no opinion)
17 (21.0%)

(Other: please comment)
0 (0.0%)

cat_77: Picture of Ghost with booze (Default)
[personal profile] cat_77

Title:
Safari Compatability

Area:
entries

Summary:
Allowing scrollable entry boxes compatable with iPad's version of Safari to make it easier to edit.

Description:
The iPad version of Safari does not permit scrolling in the entry boxes (like what I am typing in now), which makes it quite difficult to read through and edit entries that are longer than one "box worth" of information. This holds true for the original entry prior to posting, as well as attempting to edit a pre-existing entry. As there are no scrolling arrows on the iPad keyboard (only the Bluetooth accessory), you cannot simply use those within the entry box to get back up to an earlier part of the entry.

LJ has the same issue, but has an iPad compatable app which you can use instead. Understandably so, it does not crossover to any other journal site so you can only use it for LJ and not DW, which I much prefer to use.

Is there any sort of coding fix to allow this (likely a frames-related issue), or possibly a DW app in the works?

Much appreciative for any information you may be able to provide.

Thanks!

Poll #8379 Safari Compatability
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.4%)

(I have no opinion)
26 (70.3%)

(Other: please comment)
1 (2.7%)

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] 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


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

shiyiya: Shiyiya, a very pale white girl with brown hair and eyes. (Default)
[personal profile] shiyiya

Title:
Bullet points in cut tags?

Area:
entries

Summary:
Trying to put a cut tag on text that includes bullets breaks the formatting of the post really badly, this seems like it should be fixed

Description:
I wrote a post including a section with bullet points, then tried to cut tag most of the body of the post, including the bulleted section. Only the part above the bullets was actually behind a cut in the published post, there were extra broken html tags showing (</div>), and it took a lot of beating on it and hunting in the html for tags to delete (and turning off the bullets), and moving the </cut> tag to get the post to work correctly again.

ETA: Since I seem to have phrased this less clearly than I intended, what I tried to cut was formatted like this:
 

Blah blah wolf wolf.

  • One
  • Two
  • Three

Wibbly wobbly timey wimey.

The cut only took 'Blah blah wolf wolf.', and left a </cut> tag hanging out after 'wimey.'

Poll #5995 Bullet points in cut tags?
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

Should be implemented as-is.
23 (63.9%)

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
11 (30.6%)

(Other: please comment)
1 (2.8%)

northern: "northern" written in gray text across a raven (Default)
[personal profile] northern

Title:
Fix icon display on icon mouseover

Area:
Icons

Summary:
When I mouse over an entry's icon, the icon shown with the displayed information is elongated into a rectangle, distorting the image. Fix it so it's square.

Description:
See summary.

I don't think this used to happen. Possibly it doesn't happen with all styles or browsers, but it does for me with Transmogrified, IE8.

I looked through the entries here tagged "icons", but I couldn't find anything about this. I apologize if it's already been mentioned elsewhere.

Poll #5120 Fix icon display on icon mouseover
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (23.3%)

(Other: please comment)
3 (7.0%)

katieastrophe: selfie photo of katie in krakow, poland - wearing a black coat, black tshirt, & red trousers, & smiling (Default)
[personal profile] katieastrophe

Title:
Konamify Dreamwidth

Area:
site scheme, or something?

Summary:
Add an easter egg to the site triggered by the Konami code.

Description:
Many websites have "easter eggs" - little surprises for people when they do certain things, visit certain websites, etc. They're usually triggered by the Konami code/command (up up down down left right left right B A) and generally serve little purpose other than to amuse the people who discover them, but if things cause happiness, surely that's a purpose in itself, right? ;-)

Examples:
* http://www.php.net
* http://www.google.com/reader

Dreamwidth, to the best of my knowledge, does not have any Easter eggs. I want to propose that there should be one!

Technical notes: websites using them often add an Enter to the end of the series of keystrokes so as to define them from regular navigation of the website. The series of keystrokes are detected using jQuery. This is all I really know of *how* it's done, and it may be way more complicated than I'm guessing, but I'm hoping it wouldn't be too much work, code that someone could have writing, that would then bring joy to the end users :-)

Poll #1924 Konamify Dreamwidth
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
22 (56.4%)

(I have no opinion)
10 (25.6%)

(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