dw_suggestions | Entries tagged with site: display settings

Title:
Add time/date stamp to Inbox messages

Area:
Inbox, messages

Summary:
The Dreamwidth Inbox is set up to stamp any incoming messages, be they comments or PMs, as having arrived nth seconds/minutes/days/weeks/months/years ago. I'd like to see those stamps added to or replaced by an actual time/date stamp.

Description:
The Dreamwidth Inbox is set up to stamp any incoming messages, be they comments or PMs, as having arrived nth seconds/minutes/days/weeks/months/years ago.

(And I have to speak to semantics here; "34 seconds ago" is admittedly a pretty precise date/time/stamp, but "two weeks ago", IMO, very much isn't.)

My suggestion is since we already have an Inbox function for date/time stamps (it's just not a date/time stamp) to either change it from [posted, received] 'nth seconds/minutes/days/weeks/moths ago' to putting an actual date/time stamp on it, like the UTC date/time stamps we have in DW's comment sections, or else to simply add the date/time stamp to the [posted, received] 'nth seconds/minutes/days/weeks/moths ago' stamp we already have.

I discovered this was A Thing after returning to a neglected PM in my DW Inbox today and realizing I'd have to check my email to figure out exactly when it was sent. I can't stay on site to do that. And it made me feel bad that I'd have to hold up my reply a bit longer as I searched for the email notification so I could reply by saying: "...about the message you sent last Wednesday".

(Again, there are some semantics at work: I could get a calendar and count backward from today to determine what day/possibly month/possibly year "six days ago" was, but like checking my email for the date/time, it's another step I'd have to go offsite or into an OS or phone app to take.)

The system is not too difficult to use to learn when comments were posted (just check the entries comments were posted on) but it's also true no account holder on Dreamwidth can determine, merely by viewing their Inbox notifications, exactly when that was.

Poll #18016 Add time/date stamp to Inbox messages

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
6 (13.6%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (11.4%)

(Other: please comment)
0 (0.0%)

equationhouse

Title:
Having the option of tags appearing at the TOP of entries

Area:
tags

Summary:
Having the option of displaying tags above the actual text portion of an entry would be beneficial in many ways, detailed below.

Description:
As things currently stand, I am under the impression tags appear under the main portion of an entry, and that there is no way to choose otherwise. I remember on LJ there was an option to display many things about an entry above it instead, such as mood, location, etc. I feel that having similar options here on DW, particularly regarding tags, would benefit a great number of people. Particularly, I know that it would help myself and a great deal of my friends who would benefit from having a choice other than completely cutting entries that might be of an upsetting or "triggering" nature.

Tagging entries as triggering is, so far, rather ineffective, since people tend not to see the tags until they have already read at least a good portion of an entry. If these tags were, however, to be placed above an entry, it would be much easier to avoid reading potentially upsetting entries if desired.

Poll #12621 Having the option of tags appearing at the TOP of entries

This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 46

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.2%)

(I have no opinion)
15 (32.6%)

(Other: please comment)
2 (4.3%)

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

View Respondents

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

dens_extra_pups

Title:
Rating System Suggestion

Area:
journal entries

Summary:
A better rating system with more options for rating levels of communities and individual journals.

Description:
There's only three levels of journal classification. The "Safe for everyone" classification is what I'd consider G to Y7 rating, which is right where it should be, so there's no problem there. The "Should be viewed with discretion" triggers a tag that reads "NSFW" on all the entries, which borders on a bit too high of classification, in my opinion. I understand that the "18+" warrants the "NSFW" tag, which is as it should be. I think that there should be more levels of classification between the "Safe for everyone" and "Adults Only 18+", as there are a lot of things that fall in between there, and most journals would likely not come close to needing an "NSFW" tag.

Ideally, the levels of classification would be as follows:

"Safe for everyone": Leave it as it is.
"Cautious": Around PG-13 level.
"Some discretion advised": Bordering on R rating.
"Adults only 18+": Leave it as it is.

Poll #10250 Rating System Suggestion

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
3 (3.9%)

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

Shouldn't be implemented.
56 (73.7%)

(I have no opinion)
15 (19.7%)

(Other: please comment)
1 (1.3%)

pacific_rain_acim

Title:
"Order View" button enabling viewers to see entries in EITHER oldest first OR newest first

Area:
Journal Entry Page of journals

Summary:
Please create a drop down box, link or button that would change the appearance of a journal's main page from the current default "Newest Entry First" to an optional view of "Oldest Entry First"

Description:
Ok :) The idea is basically what ever they do on shopping sites and in windows, where you can hit a button at the top of a column and choose to have the most recent or most distant date first. (Or highest price & lowest price.)

1. Issue to improve: Any journal that is about a process, telling a story or play, history, building of anything, diary, ...
For instance - I just created a journal to be focused ONLY on what I'm learning as I study A Course In Miracles. I wish that viewers of that journal could choose to see the beginning of the journey first - and so the First entry on top, second in second place, etc. In other words, I wish this journal had an option to show up Oldest Entry First. People starting to look at A Course In Miracles in the future might find it comforting to see what someone thought and be able to talk about it as they were reading the same pages. Also if I like it, and read it again in the future, it would be easier to follow along with myself the second or fifth time around.

2. Why my solution is best: IDK about "best" but it's easiest for the journal owner. The only other one I can think of is to use an enormously long system of tags...a tag for every 10 pages or every date? Or the option below - of adding stock journal styles that automatically show up as Oldest Entry First.

3. Problems: there would be code that would change the links at the top of every journal, that would probably be hard. Someone would just wake up and see a new button or link "Order View" next to "Recent Entries" - but for you guys it would probably be a big code?

4. Other Ways: There could be a set of the stock journal layouts that were ONLY set to "Oldest First." We could just go in and search "Oldest First" and a set of them would come up. It would be harsh, as it takes a lot of time to get your fonts, colors, etc right. But we could do it over if it really mattered to us.

*****Unless you created an Oldest First alternate down at the bottom of the layout options page - where you now have a choice of how your columns appear.

I don't know which would be cleanest and easiest for you guys.
* added button/link to each journal that switches the view of dated entries from newest on top default, to Oldest First.

* set of journal layouts that are just coded to default the Oldest First in the entries section

* a template that can be layered on or removed (like those column options at the foot of the style page)

Poll #9497 "Order View" button enabling viewers to see entries in EITHER oldest first OR newest first

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (10.5%)

(I have no opinion)
21 (36.8%)

(Other: please comment)
1 (1.8%)

timeasmymeasure

Title:
Be Able To Customize "Member Posts" Text In Communities

Area:
communities, customization

Summary:
We should be able to customize the navigation text for the reading in page in communities.

Description:
Currently, the reading text for communities defaults to "Member's Posts", which makes sense. However, it also makes sense that we should be able to customize the text in the 'Customize Journal Style - Text' page like we can with the other navigation links.

Poll #9397 Be Able To Customize "Member Posts" Text In Communities

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
19 (31.7%)

(Other: please comment)
0 (0.0%)

montuos

Title:
Add custom option for Image Placeholder size

Area:
display settings

Summary:
Add one more option to the Image Placeholder setting at http://www.dreamwidth.org/manage/settings/?cat=display to allow defining a custom size.

Description:
There are currently four options for the Image Placeholder setting. You can set it to use placeholders always, never, for medium images (320x240 pixels) and up, or for "large" images (640x480) and up.

I have never used this setting because 640x480 doesn't seem all that large to me and I'm fine with a bit larger than that too. However a recent suggestion requesting 800x800 items [http://dw-suggestions.dreamwidth.org/1285370.html] reminded me that I do have my limits, and brought the tool back to my attention. I would like to add one more option to customize separately the largest height and width of the images we're willing to load.

Everybody's screen size and shape is different, we all prefer different sizes and shapes for our browser windows, and we all have different tolerances for the size of what we want to see. I would like to be able to use placeholders at a larger size, but I think adding a custom option would be better than simply increasing the threshold to an arbitrary size. A custom option would be more flexible, not merely allowing users to specify a larger threshold, but also allowing those whose screens/windows are more portrait-shaped than landscape to allow taller but limit wider images to fit better.

That all being said, even if having a custom option to specify the height and width separately is not feasible (I have no idea how this tool actually works), I'd still like to have one more larger option for using placeholders.

Poll #8937 Add custom option for Image Placeholder size

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (7.1%)

(I have no opinion)
25 (44.6%)

(Other: please comment)
0 (0.0%)

montuos

Title:
Mobile page/regular page toggle button

Area:
usability

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

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

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

Poll #8903 Mobile page/regular page toggle button

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.3%)

(I have no opinion)
22 (27.8%)

(Other: please comment)
0 (0.0%)

chagrined

Title:
Abolish 800x800 pixel embed limits

Area:
Entries

Summary:
Remove 800x800 pixel embed limits so users can embed HD video content in their journals

Description:
Currently DW's code limits all embedded objects (this generally impacts embedded videos) to a height and width of 800x800px maximum. Users can post larger embedded objects but they will be placed inside a scrolling iframe of those maximum dimensions (thus, blocking part of the embedded object from view). Users may want to post larger embedded videos in their journals. My suggestion is to abolish the limit. Here are some problems/issues/alternate implementations and why I think this is the best solution:

1. Problem: Other users may not want to view embedded content of this size.
Why I still support my solution: Users can currently only post embedded objects in journal/community entries anyway, not in comments. A user can already post pictures of any size in an entry without a cut or without resizing the picture. This is a matter of personal decision and community standards which people already address by moderating communities with posting regulations, by deciding what communities to follow, etc. I feel the same should apply to embedded content like videos, with a user deciding what/how they will post in their own journal.

2. Possible now-less-meaningful reason for this in the past: I don't know, but I suspect this bit of code may have been written in times when more users still had much smaller screen resolutions, and also when there wasn't as much HD video content circulating on the web. Now that many users have larger resolutions and there are many more HD videos out there (and users may create their own HD video content they wish to share, etc.) changing the code would let users take advantage of this.

3. Alternative option: Instead of abolishing the limit, it could be increased and changed to some other value. Possibly some common resolution could be used as a maximum guideline, such as 1280x720 or 1900x1080.
Problem: If wider support for larger resolutions continues in the future, this may have to be changed again, but it is easy enough to change that this isn't that big of an issue, I suppose. However, it might still prevent some users from embedding the content they wish to embed.

4. Other issues? I don't know whether the method DW uses of embedding objects causes strain on DW's servers based on the size of the object being embedded, since objects are still hosted elsewhere. However, since I can currently already embed objects with a height or width greater than 800 px (they just end up obscured from view by the containing iframe), I suspect that even if this is an issue, the current implementation isn't saving the servers in any way.

Poll #8876 Abolish 800x800 pixel embed limits

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
12 (18.2%)

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

Shouldn't be implemented.
18 (27.3%)

(I have no opinion)
22 (33.3%)

(Other: please comment)
3 (4.5%)

turlough

Title:
Confusing display settings for entry/comment pages

Area:
entries, display

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

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

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

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

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

Poll #8857 Confusing display settings for entry/comment pages

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (15.4%)

(I have no opinion)
18 (34.6%)

(Other: please comment)
7 (13.5%)

foxfirefey

Title:
In-line Adult/NSFW Expansions

Area:
Reading page

Summary:
You know how we can expand cuts in line? Yeah, I want to be able to do that with collapsed adult/NSFW content.

Description:
I love, love, love expanding cuts in-line. I think most of us agree it's an awesome feature for not breaking the flow of reading pages. However, collapsed adult/NSFW content is similar to a cut, but I cannot expand it inline. If I could do so, the entire experience would be more cohesive (not having to click through not one but two page loads to get to the content), and it would help me read the people who inexplicably mark their journals 18+ without having much of any adult content at all, while still letting me hopefully avoid entries people marked 18+ that I might not want flashing on my reading page every time it loads.

Because of the nature of this versus inline cuts, there might need to be an extra dialog to confirm expansion upon clicking. This still might carry the risk of people accidentally loading content they didn't want to see; that's about the worst drawback, but I think the advantages outweigh it.

I'm hoping that the infrastructure used to do inline cuts could be easily adapted to expanding collapsed adult/NSFW entries.

Poll #8847 In-line Adult/NSFW Expansions

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (21.3%)

(Other: please comment)
1 (1.3%)

unicorn

Title:
top level/flat comments as default entry view option

Area:
Site's view style as implemented through Manage Account page

Summary:
The My Account Settings page gives us the option of ticking a box that will show all entries in our own style. Why not further customize the entry view defaults using the newly available Top Level and Flat comment page options?

Description:
The "View comment pages in your own style" option under the Display section in Account Settings is a simple way to further customize your Dreamwidth experience. It operates by automatically displaying links to other peoples' entries with the addition of an "?style=mine." You can always manually remove that part of the link if you want to view the original style, and it makes reading comment pages easier for many people who dislike having to deal with a bunch of different styles.

Because the new "Top Level Comment" and "Flat" options for comment pages are also accessed via link changing (adding "&view=top-only#comments" or "&view=flat#comments" to the end of the existing link), it seems to me like it would be simple to add another ticky box under the Display section: "Comment Page Default View" or something of that nature, with a dropdown menu containing the options Threaded, Top Level, and Flat - the way the Entry View Style looks right now, basically, with a similar function. This would be even easier to maneuver around than the ?style=mine change if you got to a top level comment page and decided you wanted to see the threaded version, because the links to different styles of comment pages are already automatically available at the top of every entry.

This would be useful for people whose reading lists and preferred reading areas on the site tend to be either extremely large or extremely small. A default top level comment view would easily let you see what topic discussions were being started in extremely large posts without having to load a thousand comments, and flat only would let you see everything being said at once in smaller posts (you'd just have to be careful not to click 1k comment monsters casually if you had that option turned on!)

Honestly, if only one of these could be implemented, a default top level view seems more potentially useful to me, and maybe only a few people would use even that. But since this is so close in execution to an option already available to us, it seems to me (though I have no background in coding to verify this!) that the effort required to offer either or both of these as potential default views as well would be worth the payoff.

Poll #8831 top level/flat comments as default entry view option

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (11.1%)

(I have no opinion)
22 (40.7%)

(Other: please comment)
1 (1.9%)

ninetydegrees

Title:
Account Settings: merge 'Comment Pages' option with 'Entry View Style' option

Area:
settings

Summary:
See below as it's quite complicated.

Description:
On Account Settings [http://www.dreamwidth.org/manage/settings/?cat=display], you have two options:

1- Comment Pages - View comment pages in your own journal style

This is the option DW inherited from LiveJournal.

When enabled, clicking on 'Leave a comment', 'Read comments', a permalink or a cut anywhere on the site will append style=mine to the target URL. Comment and reply pages get therefore loaded in your own style or the site skin if you've disabled custom comment pages.

2- Entry View Style - When viewing entry pages (including yours), use this style: Original Style/Site Skin/My own style/Light format

This is the new option Dreamwidth implemented.

When enabled, comment and reply pages always get loaded in the style you've chosen. This is also transparent as nothing gets added to the URL. Magic!

As you can see, the two options are very similar and even overlap in some cases*. The main difference between the two is that option 1 requires you to click on some specific links while option 2 doesn't. If someone links to an entry page in their post and you click on the link, option 1 will not load it in your style. Option 2 will. If you click on the cut text, both options will load the entry in your style. The other difference is that one changes the URL while the other doesn't.

*To prevent this, option 2 isn't used when option 1 is and vice-versa. Except not always. If you have selected the light format for option 2 then it overrides option 1 for instance. As I said, it's complicated.

I suggest the first option to be phased out and to automatically set option 2 to 'my own style' for users who had checked option 1.

Why? I think option 1 seems simple but is actually uselessly complicated, and having these two options seems confusing to me. I also wonder whether many people chose to set 1 but not 2 and did so deliberately. From comments I've seen here and there, some people don't understand that entry pages and comment pages are one and the same, plus the description text for the the first option is vague because explaining how this option works exactly is impossible. It gets even more complicated if you add the fact that once you've got style=mine added to an URL, you're stuck with it so any link you will click on the page will get style=mine too. And let's not talk about Nav Strip overrides.

But what do I know, right? Hence this suggestion to see if it's a good or a terrible idea, and also to know why someone would deliberately use option 1 and not option 2 because it's intriguing. *g*

Poll #7847 Account Settings: merge 'Comment Pages' option with 'Entry View Style' option

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (11.1%)

(I have no opinion)
14 (31.1%)

(Other: please comment)
1 (2.2%)

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

View Respondents

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

turlough

Title:
Option to make archive and calendar week start on a Monday

Area:
Archive and sidebar calendar

Summary:
There should be an option that lets you set Monday as the first day of the week in the archive year view and in the calendar module.

Description:
As a European I'm always thrown to see the week start on a Sunday in the archive year view and in the calendar module. I think that, just as we have the option to set time to display as 24 hours instead of AM and PM, we should have the option to set Monday as the first day of the week. It's a small thing but I think it would be a nice way of showing that DW isn't only for people from the US.

Poll #5992 Option to make archive and calendar week start on a Monday

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
18 (22.5%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (13.8%)

(Other: please comment)
0 (0.0%)

tree

Title:
Include local time for entries on reading page

Area:
reading page

Summary:
Include the local time for an entry on a user's reading page as well as/instead of the poster's time.

Description:
At the moment, entries on the reading page are date stamped with the poster's time zone. I would find it really useful to have the option of seeing that date and time in my own time zone.

For example, the most recent entry on my reading page was posted at Nov. 27th, 2010 10:05 am. I know it's the most recent post in my circle, but I have no immediate point of reference for determining the corresponding time in my time zone. If I want to do that, I have to look at the poster's profile to determine hir time zone. And that only works if zie has entered the (correct) location.

We currently have the option for comments to be date stamped with the local time, so it might not be terribly difficult to implement. On the other hand, it might be, due to comments being static and the reading page being dynamic. The local date stamp would only appear as part of the aggregate page and not the original. That might make things explode.

I think it would be preferable to have both the poster's time and the local time displayed, but that may not be possible.

Drawbacks of implementation might be server load, although I can't imagine it would be a huge issue. If it were a feature you could choose to switch on, then anyone who didn't want it could simply leave it off.

Poll #5515 Include local time for entries on reading page

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
12 (20.3%)

(Other: please comment)
1 (1.7%)

twisted_times

Title:
Support non Gregorian calendar formats across Dreamwidth

Area:
Posting, commenting, profile dates

Summary:
Some users may want to see date formats displayed in calendar formats other than the Gregorian Calendar

Description:
This isn't really one I actually want myself, but I can see the utility of it for other users who are more used to, or use in tandem, calendar formats other than the Gregorian Calendar - e.g. Hebrew, ~~Islamic,~~ Chinese, Japanese, Coptic.

Code already exists in both Perl and PHP for converting between different calendar formats, so the conversion probably won't be problem so much as its implementation throughout the code.

I suppose the main issue is how much demand there would be for this functionality from the userbase.

Poll #5108 Support non Gregorian calendar formats across Dreamwidth

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (5.2%)

(I have no opinion)
22 (37.9%)

(Other: please comment)
1 (1.7%)

sporky_rat

Title:
Date Changing

Area:
Entries

Summary:
Changing Dating Styles

Description:
I know I'm not the only one who uses the dating style of DD/MM/YYYY instead of the American style of MM/DD/YYYY.
I'd like to suggest that the dating style be something that's a choice, not just hardwired.

Poll #4950 Date Changing

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
62 (84.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
4 (5.5%)

(Other: please comment)
0 (0.0%)

torachan

Title:
Remember ?style=mine when moving between entries in a journal

Area:
entries

Summary:
If I'm reading one entry in someone's journal with the ?style=mine formatting and I hit next/previous, it should retain ?style=mine.

Description:
Basically what it says in the summary. It would be nice if when going forward or backward in someone's journal, I didn't have to take the extra step of adding style=mine on each entry, but could have it remember it from one entry to the next.

Or even better, if there were a setting where I could have all pages on DW show in style=mine (or the site scheme, which is what I use) so I never had to see other people's unreadable, unnavigable styles.

Poll #3892 Remember ?style=mine when moving between entries in a journal

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
1 (1.6%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Settings: date display option

Area:
settings

Summary:
We'll soon have the shiny 24h time display option. Can we please have something for dates?

Description:
Let users choose how they want dates to be displayed on the site (and in journals which haven't customized it?): yyyy-mm-dd (i.e. the current format), mm-dd-yyyy or dd-mm-yyyy.

I don't care about separators ( - or / or .) but being able to choose the order these are displayed in would be great. The current format isn't used in my country and I often confuse month and day.

Edit to clarify:

I'm suggesting it be implemented exactly the way the 24h option has been implemented: "this will respect the viewer's preferences in sitescheme pages, and whenever the journal owner has not customized the time for their journal."

Meaning that if someone's overridden the way time is displayed in their layout via Customize/Advanced Customizations, the viewer's own setting won't be applied. The same way you see one's chosen colors, chosen font size, etc. unless you use ?style=mine.

Comments suggest that some users would rather have their settings override all and any other user's settings/customizations. Discuss. :)

Poll #3304 Settings: date display option

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
10 (19.2%)

Shouldn't be implemented.
2 (3.8%)

(I have no opinion)
3 (5.8%)

(Other: please comment)
1 (1.9%)

Dreamwidth Suggestions

Add time/date stamp to Inbox messages

Having the option of tags appearing at the TOP of entries

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

Rating System Suggestion

"Order View" button enabling viewers to see entries in EITHER oldest first OR newest first

Be Able To Customize "Member Posts" Text In Communities

Add custom option for Image Placeholder size

Mobile page/regular page toggle button

Abolish 800x800 pixel embed limits

Confusing display settings for entry/comment pages

In-line Adult/NSFW Expansions

top level/flat comments as default entry view option

Account Settings: merge 'Comment Pages' option with 'Entry View Style' option

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

Option to make archive and calendar week start on a Monday

Include local time for entries on reading page

Support non Gregorian calendar formats across Dreamwidth

Date Changing

Remember ?style=mine when moving between entries in a journal

Settings: date display option

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate