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

Title:
Improvements for preview pop-ups


Area:
entries


Summary:
This is a new version of my previous suggestion : https://dw-suggestions.dreamwidth.org/1492300.html. As lightboxes, which are what I was thinking of, are entirely unpractical and users prefer pop-ups it is best to keep preview windows as pop-ups. However, I find previews a bit impractical in their current form because they don't let you post your entry, nor get closed automatically when you've posted it. I'm also wondering if we need to see more than your entry in the preview window. If I preview my entry in the site skin for example, a good portion of the window (viewport) is occupied by the site header, making me scroll down if my entry is a bit long. Do you, fellow users, find being able to see (and use) the header useful?


Description:
These are the things I'm suggesting but feel free to come up with other ideas, or better ways to implement them:
*A 'post your entry now' button (copyright to sporky_rat) in the preview window which will post your entry (duh) but also close the preview window and trigger the success page in your main tab.
*As the preview window is not being updated dynamically, a 'back to editing' button which closes the preview window and brings you back to your editing tab (you're still free to refresh the window if you prefer keeping both tabs open and doing things that way)
*Or, if that can be implemented, a preview window which is being updated as you type (jducoeur also mentioned having editing and preview side-by-side or top-to-bottom which I think is an interesting idea. I don't know how accessible it is, if users would prefer it, how it would work on smaller screens, etc.)
*A preview window where the actual entry is more prominently displayed and other elements are hidden or do not take so much space (like a light version of the site skin/your journal or maybe only for users who display entries in the site skin?).





Poll #18050 Improvements for preview pop-ups
Open to: Registered Users, detailed results viewable to: All, participants: 22


This suggestion:

View Answers

Should be implemented as-is.
6 (27.3%)

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

Shouldn't be implemented.
5 (22.7%)

(I have no opinion)
8 (36.4%)

(Other: please comment)
0 (0.0%)

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

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

stargazered: (Default)
[personal profile] stargazered

Title:
Optional "Re-Posting" to add on to current "Share This Entry"

Area:
Share This Entry

Summary:
A re-posting option (that can be turned on or off, so up to the poster) that allows posts to be shared and appear in journals and reading pages like re-tweeting: redirects to the original post (so original poster still controls it)

Description:
The "Share this entry" of Dreamwidth is reaching a point where it's lacking, as it depends only on email and nothing else! Keeping what it has now (emailing), more options should be added. Like Re-Postng, only if the account or community turns this option on. This can be like Retweeting or Replurking: It appears the journal (thus counted as an update) and consequently the reading page of those subscribed to that journal, but it shows the original post and redirects you to it once clicked.

I believe Facebook has something like this, where "(user) shared -> (details here)" and it's the original.

Therefore the original poster still has all power of their post, should they want to edit or delete it. The problem with sites like Tumblr is that reblogging makes it an entirely new and separate post, so the original poster loses control of it (like if they wanted to delete or edit, they cannot because it will still circulate around, even when they delete their accounts). This will help with the exposure of many posts that can welcome plenty of discussion with this already excellent commenting system.

Also, not everyone wants their posts to be reposted in such a manner, even if their account is primarily public, because of personal and privacy reasons. The option to turn it on and off will be required (including whole communities to have the option to turn it on and off, since some communities are personal?)

Reposting also should not be an option for locked posts, obviously for privacy reasons.

Also if possible, individual posts can have the option to be reposted, like how currently some posts can have specific levels of content ratings.

As for a count of how many times it's been reposted, I'm not sure if that is required, but it seems to be consistent with most places that allow this form of sharing, so maybe on or off?

Dreamwidth's always been wonderful in keeping good privacy options, good flexibility when it comes to filters and keeping power to the poster. So if it has a sharing option like this, it should have one that upholds its ideals while still giving us that option to spread posts around. At the moment, the ideas and points I have suggested keep the reposting of Dreamwidth posts to just other Dreamwidth accounts, just to keep this simple first.

Poll #18013 Optional "Re-Posting" to add on to current "Share This Entry"
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)
17 (37.8%)

Shouldn't be implemented.
14 (31.1%)

(I have no opinion)
3 (6.7%)

(Other: please comment)
1 (2.2%)

pseudomonas: (Default)
[personal profile] pseudomonas

Title:
In Case of Emergency write-only access

Area:
Posting

Summary:
Give limited access to a small number of other DW users to make posts on your behalf, with restrictions. [New feature suggestion]

Description:
What I want is a write-only function where (say) I nominate (say) you as an In-Case-of-Emergency poster for if I'm (say) ill in hospital; you can then post to my DW, but without any ability to see locked entries, modify settings, modify circle, or anything else; furthermore there'd be a prominent heading applied to any posts you made saying "posted by [YOURUSERNAMEHERE]", so impersonation wouldn't be possible. I can always delete or modify the posts that you have made on my behalf. Crossposting would work as normal.

Other methods:
a) implement this as an external website, using OpenID to verify you and store my password. Requires competently-run, secure, trustworthy third-party site. Need to remember to log in to that site every time I change my DW password.

b) give you my password. Trusts you to keep it safe, not lose it, and I have to tell you every time I change it. Allows impersonation and account-modification.

c) Give you my post-by-mail credentials. As above, but doesn't allow impersonation, eats an address slot per person, and only works for paid/permanent users.

d) The one that usually gets done these days - you making unlocked posts and hoping that enough of my circle see the post and that I don't have anyone I'd rather didn't know. This has the advantage of being simple, but is really not an effective solution to the problem.

Considerations:
I would favour the poster having the ability to post using any publicly-visible security setting that would let the poster see the post (at least "access-list-only" or "public") and possibly edit posts that they have themselves made (but not remove the header saying that the post was made by them). I don't see much need for anything beyond that; they can comment on posts as themselves.

I would envision small number of people given these posting privileges, though I don't have a particular limit in mind, and I don't see a really good reason to put a hard-limit on things.

There's always a risk that someone will post a malicious or spurious report, but really they can do that *anyway* via method d), it's called lying, and it's a social problem that is solved by only authorizing people that you trust not to do that kind of thing.

Poll #15788 In Case of Emergency write-only access
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
15 (24.6%)

Shouldn't be implemented.
2 (3.3%)

(I have no opinion)
12 (19.7%)

(Other: please comment)
0 (0.0%)

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

Title:
Admin posts: connect 'as admin' post with 'admin' icon keyword

Area:
icons, communities, entries, comments

Summary:
If one has an icon with the 'admin' or '_admin' keyword automatically select it when making a post or a comment as an admin (I meant when you tick the 'as admin' checkbox).

Edit: looks like _admin or something even more unusual would be better as there would be a good chance *only* users who wanna have this would.

Description:
Not sure automatic selection is possible in which case it could be automatically use (so you wouldn't even have to select an icon the way it works at support). The latter could be problematic if you wanted to use a different icon for once.

Poll #15508 Admin posts: connect 'as admin' post with 'admin' icon keyword
Open to: Registered Users, detailed results viewable to: All, participants: 35


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.7%)

(I have no opinion)
22 (62.9%)

(Other: please comment)
1 (2.9%)

katherine: Girl with glasses: Fuzzy cat with a folded pair of glasses by her paw. (Default)
[personal profile] katherine

Title:
Add "Edit entry again" to Journal entry was edited Success page

Area:
entries

Summary:
Add "Edit entry again" to Journal entry was edited Success page "From here you can" options.

Description:
The page Success when one has edited a journal entry is:
<blockquote>
Success

Journal entry was edited.

From here you can:

* View this entry
* View your journal entries
* Manage your journal entries
</blockquote>

Having another option be "Edit this entry again" would be handy when one is making a number of changes to the same entry in a row, or saved and immediately realised another edit to make.

Poll #15507 Add "Edit entry again" to Journal entry was edited Success page
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
54 (88.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (11.5%)

(Other: please comment)
0 (0.0%)

zaluzianskya: (Default)
[personal profile] zaluzianskya

Title:
A way to easily copy and paste Create Entry setting preferences

Area:
Posting

Summary:
It would be nice if an option could be implemented, once the new Create Entries page is out of beta, to quickly and easily copy-and-paste one's setting preferences.

Description:
The new Create Entries page, which is currently in beta, has a lot of different options to customize the page to a user's liking. But for users who have multiple accounts, for RPing or other reasons, remembering those options and applying them the same way to several different accounts might be troublesome. I'm opted-in to the beta and I have the page set up in a way I like for this account, but when I switch to other accounts it's jarring because things aren't the same way. I could manually set them all up in the same way (and I probably will after I finish posting this suggestion, since it's on my mind now), but it would be nice to have a way to rapidly apply all of my preferences at once.

My suggestion is to have some sort of button you can click somewhere, maybe on one of the Manage Account tabs, to generate a textual list of your preferences that you can copy, and a textbox somewhere else on the same page where you can paste those preferences and automatically apply them. (Once you've logged into the account you want to apply them on, of course.) The list would read something like:

entry_field:column;show_panels:entry-link,tags,currents,journal,comment-settings;panel_arrangement:(some sort of... thing to indicate what order and location the panels are arranged in)

Obviously that's just garbage spewed out by someone who doesn't have the faintest clue how this stuff works, so I wouldn't expect it to look exactly (or even necessarily remotely) like that. But something along those lines!

It would also be nice for users who have a specific way they want their page layout to look, but feel like temporarily changing it either to see if there's another way they like better, or perhaps for Support troubleshooting; they could save their preferences and easily revert to them this way.

Poll #15505 A way to easily copy and paste Create Entry setting preferences
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (8.3%)

(I have no opinion)
19 (52.8%)

(Other: please comment)
0 (0.0%)

one_step_will_take_me: (Default)
[personal profile] one_step_will_take_me

Title:
the ability to insert emoticons in entries

Area:
entries

Summary:
Sometimes it's easier to express things with emoticons and smiles than with words

Description:
sometimes it's easier to express things with emoticons and smiles than with words, so you could make it possible for us to have insert emoticons button in the rich text bar within the others possibilities we have to post an entry such as font colour, font size, images, media, links... I usually insert emoticons using the insert images button, but since there'a lots of it in all sizes sometimes it doesn't look beautiful to see in the blog, with a small font and a big emoticon.

Poll #13976 the ability to insert emoticons in entries
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
6 (11.3%)

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

Shouldn't be implemented.
30 (56.6%)

(I have no opinion)
11 (20.8%)

(Other: please comment)
2 (3.8%)

hebethen: (Default)
[personal profile] hebethen

Title:
Small change for filter option when posting an entry

Area:
Post an entry

Summary:
Right now, in order to designate an entry as viewable by a certain filter, one must select 'Custom' from the 'Show this entry to:' dropdown menu. Only then do the individual filters show up as checkboxes. I think it would be clearer if the option said something like 'Access Filter', or if the filter checkboxes were visible from the get-go.

Description:
Well, I'm not sure how much more I can say about it! Just that it's not very clear to a first-time user that there are Filters, and I remember I was a bit confused as to the wording of that dropdown menu option myself. If it's just a text change, it's a pretty minor thing and I don't think there are any drawbacks or problems.

On the other hand, listing out the filters and their checkboxes right up front would also solve the issue of clarity, and streamline the selection of a filter. I never really saw the point of having filters hidden until you select 'Custom', from a user's point of view. But I understand that it's probably more complicated, codingwise, to (e.g.) have the checkboxes right there and make the dropdown automatically jump to 'Custom' when the user clicks a checkbox.

Poll #13651 Small change for filter option when posting an entry
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

Should be implemented as-is.
6 (19.4%)

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

Shouldn't be implemented.
3 (9.7%)

(I have no opinion)
9 (29.0%)

(Other: please comment)
0 (0.0%)

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

Title:
Create Entries Beta: use field w/ autocompletion and browser for moods (like for tags)

Area:
entries

Summary:
Scrolling down the very long mood menu to pick one is not my favorite thing to do. I'd rather have the same system we have for tags: one field with autocompletion where you could also enter whatever (which would get rid of the awkward 'custom mood' field) and a browse button to load a mood browser.

Description:
.

Poll #13096 Create Entries Beta: use field w/ autocompletion and browser for moods (like for tags)
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

Should be implemented as-is.
18 (40.0%)

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

Shouldn't be implemented.
3 (6.7%)

(I have no opinion)
19 (42.2%)

(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: allow users to enter a communiy name

Area:
entries

Summary:
It is currently impossible to post to an open community you're not a member of but still can post to from /update. I'd like a field to be added so I can enter a name. I admin and post to communities which allow anybody to post. I think it's a shame I have to go to the community page each and every time to post to them.

Description:
On LJ it's just one area: you can easily switch from a menu for comms you're a member of to a text field. I think it'd be a nice way to implement this.

Poll #13090 Create Entries Beta: allow users to enter a communiy name
Open to: Registered Users, detailed results viewable to: All, participants: 51


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
13 (25.5%)

(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: outline icon on hover

Area:
entries

Summary:
Add mouseover outline indicating that you can click on the icon to load the icon browser. I only realized we could do this on DW when I saw it on LJ.

Description:
.

Poll #13089 Create Entries Beta: outline icon on hover
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
35 (66.0%)

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

Shouldn't be implemented.
1 (1.9%)

(I have no opinion)
17 (32.1%)

(Other: please comment)
0 (0.0%)

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: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.5%)

(I have no opinion)
26 (56.5%)

(Other: please comment)
2 (4.3%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Add "view my entries in this community" to post-entry-creation page for communities

Area:
community membership, workflow: entry posting

Summary:
When you successfully make an entry in a community, add the link to view the rest of your entries to the little menu.

Description:
There's a list of suggested/possible/common actions to take after posting an entry, and I noticed on a recent change, that for successful posting in a community, the "edit my entries" link was removed -- for good and sufficient reason, because making that specific link work with communities was basically just not on from a developer perspective.

Something that currently exists and is relevant is the http://community.dreamwidth.org/?poster=username link, which locates all of the users entries to that community.

It would not be particularly development-difficult to add this link to the list of common possibilities, and it could help drive discovery of that really fascinating and useful feature.

Also, if someone needed to edit their past entries to the community, the entries would be listed right there.

Poll #12338 Add "view my entries in this community" to post-entry-creation page for communities
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.2%)

(Other: please comment)
0 (0.0%)

montuos: cartoon portrait of myself (Default)
[personal profile] montuos

Title:
Allow "Use the time when entry is posted" to be set as default

Area:
posting entries

Summary:
Allow "Use the time when entry is posted" to be set as default when posting entries.

Description:
It is clear from reading "Get rid of restrictions on future-dated posts" [http://dw-suggestions.dreamwidth.org/1387122.html] that there are many users who are passionate about posts being timestamped when the Create Entries page was first opened, not when composition was complete. However, there are others of us who are just as passionate that entries should be timestamped at the moment of posting, *not* at the moment (days, hours, or even just minutes ago) that we started writing the post, unless we explicitly choose otherwise.

Therefore, I would like it to be possible to set "Use the time when entry is posted" as default, or if this is not possible, then at least for the Create Entries page to remember the previous setting.

Poll #12195 Allow "Use the time when entry is posted" to be set as default
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
9 (14.3%)

Shouldn't be implemented.
2 (3.2%)

(I have no opinion)
8 (12.7%)

(Other: please comment)
0 (0.0%)

kaberett: Overlaid Mars & Venus symbols, with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett

Title:
"This post will self-destruct shortly...": automated security changes

Area:
privacy, filters

Summary:
People commonly make public posts which they do not wish to remain public indefinitely. An additional field at posting ("Change security [...] to [...] when [...] (has/have) elapsed") would remove the need to remember to make the manual change at a later date.

Description:
I repeatedly come across cases where people make a post with the specific intention of subsequently changing its visibility, for example:

(1) person with username A changes it to B. They want to flag this up to their subscribers, without creating a permanent trivially-findable public record. They make a public posting, intending to manually restrict access to said post after a week. Memory proves to be a tricksy beast, however.

(2) person wants their "current" entries to be public - on a rolling basis. That is, they *don't* want their entire journal to be public, but *do* want their initially-set-as-public posts over the last N weeks to be generally visible.

(3) person is making a links round-up (LRU); realises they've left out a link; edits the original post to include it. In order to flag this up to people who've already read the LRU and won't read closely again, they make a follow-up post to appear on people's dwrolls, highlighting that they've added a new link, with the intention of deleting the follow-up post after a few hours (at which point it is obsolete, because people who're only just catching up with their reading lists won't have seen the pre-edit LRU anyway!)


In each of these cases, it would be helpful if there were the option tree at point of posting:

Change security at later date? Y/N
Change security to? [pre-defined set of access filters, etc!]
Change security when? [hours, days, weeks...]

... such that in case:

(1) person, at time of posting, can say "make this post access-locked after a week"
(2) user can set a default behaviour of "increase privacy of all posts to [LEVEL] after a month" (where custom filters, etc obviously don't have their privacy level *reduced*!)
(3) user can make the post automatically set itself private e.g. 6 hours after initially posting


In IRC we briefly discussed the possibility of actual self-destruct - i.e. automatic deletion after a set time frame - but consensus there was that auto-deletion is an undesirable behaviour, because (a) deletion is irreversible, and (b) setting posts to private has the same effect on the reader as deleting them.

In terms of downsides, the only one that springs out at me is that - at least for my level of familiarity with the code-base - this would be an absolute *swine* to implement. However, I am very open to hearing other criticisms :-)

Poll #11815 "This post will self-destruct shortly...": automated security changes
Open to: Registered Users, detailed results viewable to: All, participants: 64


This suggestion:

View Answers

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

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

Shouldn't be implemented.
13 (20.3%)

(I have no opinion)
15 (23.4%)

(Other: please comment)
1 (1.6%)

[personal profile] alexbayleaf

Title:
Get rid of restrictions on future-dated posts

Area:
posting

Summary:
DW doesn't allow you to post a future-dated post, and then follow it with a present-dated post. There are probably other restrictions along these lines. I suspect they are all there for historical reasons that don't matter any more, and I propose we get rid of them.

Description:
I came across this bug when crossposting from my Wordpress blog using JournalPress. My Wordpress blog (and my DW, for that matter) both have their timezones set as Australia/Melbourne, which as you probably know is almost as far in the future as it's possible to be without being a hobbit. So, I posted post A from my wordpress blog, and it was crossposted. Then I went to post another post, locked to my access list, directly on my DW. I was greeted with this error message:

<blockquote><strong>Error updating journal:</strong> Incorrect time value: You have an entry which was posted at 2012-10-01 02:02, but you're trying to post an entry before this. Please check the date and time of both entries. If the other entry is set in the future on purpose, edit that entry to use the "Don't show on Reading Pages" option. Otherwise, use the "Don't show on Reading Pages" option for this entry instead. </blockquote>

Initially I was going to submit some kind of bug report, but then I got to thinking... why is this limitation there at all? It has the whiff of something that was done for historical reasons, back in LJ's early days, and hasn't been revisited.

Why do we care about future-dated posts anyway?

Before sticky posts, people used to post future-dated posts (eg. dated 10 years in the future) so they would always show up at the top of their journal. This has been superseded by the sticky post feature, though I suspect some people may still use the old technique.

<user name="azurelunatic">, on IRC, suggested that it might also have something to do with people's computers having really wacky times set on them. I can see this being a problem a decade ago, but I think almost everyone's computer these days using <a href="http://en.wikipedia.org/wiki/Network_Time_Protocol">NTP</a> to automatically set the time, yes? So this would be a much rarer thing than it used to be.

I don't actually have a good feeling for what the solution is here, but I wanted to raise this suggestion to ask:

1) what benefit is there to limiting posting in this way?
2) do those benefits still apply, or are they historical only?
3) can we just get rid of it?
4) if not, can we modify it so that only egregious badness is prevented, but posting from a third-party client in another timezone is permitted?

For the purposes of voting, please consider the suggestion to be "get rid of future-date limitations on posts to the greatest degree possible."

Poll #11813 Get rid of restrictions on future-dated posts
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
10 (17.9%)

(I have no opinion)
13 (23.2%)

(Other: please comment)
2 (3.6%)

torachan: (Default)
[personal profile] torachan

Title:
Deleting the text of an entry should not delete the entry or should warn first

Area:
Entries

Summary:
Deleting the text of an entry should either not cause the entry to be deleted, or if it does, it should warn before deleting.

Description:
Back in the day, the only way to delete an LJ entry was to delete the text and then save the entry. Now, of course, on both LJ and DW, there is an actual delete button. Using the delete button gets you a "do you really want to delete?" type message before it deletes the entry. However, the old way of deleting still exists, and worse, it doesn't ask you if you really want to delete, it just does it.

There are many reasons why someone might delete the text without wanting to delete the entry. They might want to just keep the title and comments but no longer have the text of the entry there, or they might be testing something. (The case that prompted this post was someone getting weird whitespace issues and trying to see if they could get rid of it by saving a blank entry and then repasting in the text, but when they saved the blank entry, the entire post was deleted without warning.)

Now that a delete button exists, there's not really a good reason why deleting the text should delete the entry. If someone wants to delete an entry, there's a much more intuitive way of doing so: just click the delete button! So my suggestion is that if you delete the text, it should not delete the entry.

However, if that's not possible, at the very least there should be a warning before deletion just like there is with using the delete button. Users new to DW/LJ may not even know about the old way of deleting, and even long-time users may have forgotten it or assumed it was changed with the implementation of the delete button. There should always be a warning before something is deleted.

Poll #11752 Deleting the text of an entry should not delete the entry or should warn first
Open to: Registered Users, detailed results viewable to: All, participants: 80


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
19 (23.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (6.2%)

(Other: please comment)
0 (0.0%)

emceeaich: A close-up of a pair of cats-eye glasses (Default)
[personal profile] emceeaich

Title:
Enable Embedding GitHub Gists as Media in Posts

Area:
posting, media

Summary:
Enable adding GitHub Gists, which are embedded as scripts, in posts, via the 'add media' option so that DW users can post short blocks of formatted source code for discussion and review.

Description:
Gists are text files hosted on GitHub enabling developers to post short snippets of code for review and comment.

GitHub provides a way to embed a gist on a site, as a script file:

&lt;script src="https://gist.github.com/3290622.js?file=foo.js"&gt;&lt;/script&gt;

However, DW wisely prevents scripts from being embedded as either media or post content because XSS :)

But adding gist.github.com to a whitelist would enable coders of all skill levels to quickly post nicely formatted snippets of code for review, discussion, and comment.

Poll #11553 Enable Embedding GitHub Gists as Media in Posts
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
13 (24.5%)

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
30 (56.6%)

(Other: please comment)
0 (0.0%)

zarhooie: Girl on a blueberry bramble looking happy. Text: Kat (Default)
[personal profile] zarhooie

Title:
Make the landing page after you post an entry be more useful

Area:
entries, landing page, usefulness-a-go-go

Summary:
The landing page after a user posts an entry should have more information on it.

Description:
The landing page after a user posts an entry should have more information on it. Right now, it says the following:
Your update was successful. View your updated journal.

Crosspost requested to zarhooie@LiveJournal. You will be notified in your Dreamwidth Inbox if this attempt fails.

Now that you've posted, you can:

View the entry
Edit the entry
Add the entry to your memories
Edit this entry's tags

It would be better if it said, "Your journal has been updated with the entry titled, 'Suggestions.' It will be posted access-only, the icon tagged, 'D on Yarn' was used, and it was tagged with the following tags:"

Or something along those lines. I usually double-check my entry after posting for those few things, and it'd be nice if I didn't have to do an extra click to make that happen.

Drawbacks: It will put more information on the page, and while I personally find that to be a good thing, I'm not sure everyone will. Also, it is possible that it could cause first-page syndrome, depending on the length of some of the variables. It shouldn't on my netbook, but it could on a mobile device.

Poll #11021 Make the landing page after you post an entry be more useful
Open to: Registered Users, detailed results viewable to: All, participants: 59


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (10.2%)

(I have no opinion)
13 (22.0%)

(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