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

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

Title:
Differentiating inbox notifications from suspended users

Area:
inbox, suspension

Summary:
Inbox notifications should differentiate what kind/where a message from a suspended user originated.

Description:
Currently inbox notifications involving suspended users all have a very uninformative "(Reply from suspended user)" giving the username of the suspended user.

It would be good to at least differentiate between different types of notification (comment, private message -- poll vote? birthday notification?). It would be extra-fancy if there was more information, like, was it a comment in your own journal, a reply in another journal or community (when that goes through the inbox), a comment on something you're tracking, or other information to better contextualize what's going on.

Turns out it's startling when someone with an entirely locked journal doesn't realize they have private messages turned on, they get a message from a spammer who is subsequently suspended, and they have a sudden moment of alarm wondering if there was some kind of security incident. Situations like this could be better avoided with more context for inbox messages.

Poll #14595 Differentiating inbox notifications from suspended users
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
2 (5.6%)

(Other: please comment)
0 (0.0%)

fluffymormegil: @ (Default)
[personal profile] fluffymormegil

Title:
Option to disable tag auto-completion

Area:
tags

Summary:
Add an option to disable tag auto-completion.

Description:
The tab auto-completion system interacts poorly with at least older (2.x) Android browsers, because the text entry system on those devices does not support "overtype to erase selected text". It would be useful to have an option to disable tag autocompletion, so that users of such devices can fill in tags without heavy use of backspace.

Poll #14592 Option to disable tag auto-completion
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

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

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

Shouldn't be implemented.
11 (34.4%)

(I have no opinion)
9 (28.1%)

(Other: please comment)
0 (0.0%)

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

Title:
Make Sidebar and Tags Page Tag Counts Into Links

Area:
tags, styles

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

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

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (18.5%)

(I have no opinion)
12 (44.4%)

(Other: please comment)
0 (0.0%)

pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma

Title:
Remove sticky entries from ?poster=(mumble) community journal view

Area:
page: journal, site: community features

Summary:
When viewing entries by a specific poster in a community, like http://dw-dev-training.dreamwidth.org/?poster=pauamma, sticky entries shouldn't be displayed on top. This is because the reader is likely looking for a specific entry by author name, and the sticky entries will likely stand in the way of seamless scanning.

Description:
It's unclear to me what should happen to sticky entries by the user specified in ?poster=. wouldnt want them displayed as sticky/in sticky position. Instead, I'd have them display in normal time-of-posting order. But there may be reasons to do it otherwise, or with a controlling option in the URL or elsewhere.

Poll #13978 Remove sticky entries from ?poster=(mumble) community journal view
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (9.5%)

(I have no opinion)
15 (35.7%)

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

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

Title:
Site search refinement: not your own journal?

Area:
site search

Summary:
When using site search, is there any benefit to seeing results from your own journal along with the sitewide results, provided you can search your own journal?

Description:
If you can't search your own journal individually, site search may be the only way you have to search your own journal, and I wouldn't want to mess that up for anyone.

If you can search your own journal, is there any benefit to having results from there displayed along with everybody else? I ask because I was running a search where I was 90% or more of the entries sitewide, and I was looking for stuff I didn't already know about.

Assuming it's feature-wise desirable to exclude the journal of the logged-in user from sitewide search results (if and only if that user can also search their own journal), would it be technically feasible? (This is probably a Mark question.)

If it's desirable and technically feasible, how best to implement it? Some thoughts:

* a separate radio button besides user-search and site search
* a checkbox on site search
* just exclude them and leave a note at the top of the search results
* other people may have way better ideas

Poll #13973 Site search refinement: not your own journal?
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (38.5%)

(Other: please comment)
0 (0.0%)

erinptah: (Default)
[personal profile] erinptah

Title:
Enable Diigo to crosspost to Dreamwidth

Area:
external sites, crossposting

Summary:
I can set my Diigo account to automatically crosspost recent bookmarks to other sites, including LJ and Wordpress. Dreamwidth should get in touch with Diigo about enabling the same to DW, and should set whatever permissions are necessary for it to do so.

Description:
The summary is it, really. The only alternative for Diigo users is to manually crosspost our bookmarks on a regular basis, which is a headache for so many reasons.

Diigo's existing crossposting utility works on LJ, so it should be just as safe and workable for DW.

The main stumbling block is whether Diigo is wiling to implement the necessary changes on their end. And it seems likely that if they were contacted by administrators saying "we're willing to make it possible on our end," they would be amenable to going for it.

Poll #13641 Enable Diigo to crosspost to Dreamwidth
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (80.6%)

(Other: please comment)
0 (0.0%)

[personal profile] swaldman

Title:
Set default country according to IP

Area:
Shop

Summary:
When making purchases in the shop, it would be nifty if your country could be defaulted to a best guess based on IP.

Description:
It would be a minor convenience feature, and might involve quite a lot of work/hassle/complexity... but I thought I'd throw it out there in case somebody says "oh, that'd be easy actually" :-)

Drawbacks: Slowdown as the lookup is done; don't know whether this would be significant. Maybe there are some situations in which people would be offended by an incorrect guess?

Poll #13460 Set default country according to IP
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
23 (50.0%)

(I have no opinion)
16 (34.8%)

(Other: please comment)
0 (0.0%)

[personal profile] swaldman

Title:
Review the countries that are at the top of the "country" dropdown in the shop

Area:
Shop

Summary:
When paying by credit card in the DW shop, one specifies one's country in a drop-down. This drop-down is alphabetically sorted except for United States, which appears at the top.

Suggestion is to review which countries appear at the top.

Description:
It is fairly common for such dropdowns to promote a few most-common countries out of their alphabetical order and put them at the top of the list.

The Dreamwidth Shop does this with United States.

My suggestion is to review which countries appear at the top in this way: are there others that hold a sufficiently large proportion of the DW paid userbase to merit this treatment? I suggest that 3-5 of the most common countries should appear here, and that a separator should then be inserted in the list to make it clearer what is going on.

Poll #13459 Review the countries that are at the top of the "country" dropdown in the shop
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (11.1%)

(I have no opinion)
15 (33.3%)

(Other: please comment)
1 (2.2%)

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

pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma

Title:
Display unregistered and renamed-without-redirect usernames as struck through

Area:
site-specific markup, renaming, registration, usability

Summary:
<user name="thisusernamedoesntexist"> is displayed with no strike through when the username was never registered, or was renamed to something else without redirection. This makes it harder to spot typos, and may have minor privacy consequences in the latter case. It should be made consistent with the way usernames of deleted accounts display.

Description:
Drawback: This would introduce an incompatible change for people who relied on the current behavior to display made-up generic usernames without having to register them or find ones already registered for that purpose, like "exampleuser". Finding one suitable for that purpose - eg, not that of an actual site user or community which might feel singled out - would become harder, and maybe even impossible without actually registering it, for languages other than English.

Poll #13088 Display unregistered and renamed-without-redirect usernames as struck through
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

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

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

Shouldn't be implemented.
16 (32.0%)

(I have no opinion)
11 (22.0%)

(Other: please comment)
3 (6.0%)

jewelfox: A portrait of a female anthropomorphic fox, with a pink jewelled pendant and a cute overbite. (Default)
[personal profile] jewelfox

Title:
Add Desura to the list of sites that can be in your profile or linked to

Area:
Profile

Summary:
Desura is like an indie games version of Steam.

Description:
As long as we got a suggestion to have a Steam link in people's profiles, let's go for Desura too. It'd be nice to be able to link to people's profiles there also, using the <user name= site=> format.

Poll #13010 Add Desura to the list of sites that can be in your profile or linked to
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

Should be implemented as-is.
11 (26.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
31 (73.8%)

(Other: please comment)
0 (0.0%)

wailor: (Default)
[personal profile] wailor

Title:
Some privacy incoherence

Area:
Profile

Summary:
There's a way that allows people to know I have updated my journal with a filter entry (and they aren't inside that filter).

Description:
Ok so here's what I've noticed:

Imagine you have a few friends and you want to post an entry to prepared a surprised b-day party just for one of them. You don't want him or her to know about it so you'll post a filter entry right? but, if that friend is smart enough and have some curiosity, he or she could discover that I've posted a new filter entry. That's a problem because that person could feel upset about it thinking that I have something to hide to him or her.

The way he or she could discover it is by my profile page. There's some information that I can't hide that tells her or him that there's something new that she or he isn't allow to see. That information is the number of "journal entries" and the "last updated".

The example I wrote up there is just one of multiple cases where it'll be necessary to hide that information and I can't think a reason why I couldn't hide it.

So, my suggestion is to allow to hide that information as I do with other things like my birthday, my location, etc.

Poll #12623 Some privacy incoherence
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

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

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

Shouldn't be implemented.
32 (50.8%)

(I have no opinion)
11 (17.5%)

(Other: please comment)
2 (3.2%)

100percentmail: This is a couple's icon, paired with <user name="2ndBest"> (Default)
[personal profile] 100percentmail

Title:
Instant Messenger Icons

Area:
Suggestion for another "site=" tag

Summary:
I'd love to see an AOL site=aol/aim.com aim icon! The little yellow running man. In fact I'd love to see more "networking" site="networkingsite".coms too. The list is pretty amazing to be honest, but the AOL would be awesome. AOL/MSN/YIM etc.

Description:
The short paragraph pretty much. Sums. It up. Messenger things now that we have such an impressive list already. It's not a huge imperative thing, I just figured I'd toss it out there. I searched "AOL" and "instant messenger" and found nothing on them. I'm also surprised not to see facebook on here too, not annoyed or anything just odd not to see it on the "site=##.com" list.

I do realize under "Contact Information and Links" then "Other Sites"
there's a ton of them there to give your info, but I'd love to have the ability to do so in posts or that sorta thing without linking the icon myself and etc. Again not the biggest deal in the world but I did wanna toss it out there!

I can see all arguments for and against, we can link the icons as pictures/etc so it's not as big a deal. I'm totally there with you, this is the least of the worry of a huge site with so many upcoming awesome things going on.

Thanks so much for hearing me out! I appreciate that and know that you guys, even if you can't comment to everything, are watching and understanding. I'm not sure if I'm allowed to/should mention names, but someone on the staff helped me a lot with a recent loss even though it was above and beyond just a request to archive a journal. So I know you guys care and are watching, so a good thank you and thank you again for the read!

Poll #12620 Instant Messenger Icons
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)
2 (4.3%)

Shouldn't be implemented.
8 (17.4%)

(I have no opinion)
22 (47.8%)

(Other: please comment)
0 (0.0%)

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

Title:
Add the Recent Comments page to the /manage/ menu

Area:
comments, control pages

Summary:
http://www.dreamwidth.org/tools/recent_comments is missing from http://www.dreamwidth.org/manage/

Description:
The Recent Comments page (also known as "Manage Comments" at present) is a handy way to view and manage recent comments.

I feel it should go under the "Journal Entries" heading, as "Recent Comments", but am open to other suggestions.

Poll #12619 Add the Recent Comments page to the /manage/ menu
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

Should be implemented as-is.
20 (47.6%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (47.6%)

(Other: please comment)
2 (4.8%)

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.7%)

(I have no opinion)
20 (46.5%)

(Other: please comment)
1 (2.3%)

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

Title:
View entryprops for your own journal/administrated community

Area:
entries, self-service support

Summary:
Staff and senior support have the at-need ability to view some of the troubleshooting information attached to entries; this information could be useful to the journal owner.

Description:
All entries have under-the-hood information called "entryprops" (short for "entry properties") attached to them. Staff/senior technical support can view these at need.

Usually there's no need to view this information, but sometimes there's a simple question (like: did all my icon information successfully make it over when I imported? Generally the importer gets this right, but it's usually more reassuring to see for yourself) that could be answered. (And doubtlessly if it were readily available, there would be more helpful uses for it floating around.) It also strikes me as information that would be useful to a community administrator, if it's available to journal owners.


How would it be viewable? (For all of the cases below, this would only be for the journal owner/community admin; if someone didn't have permission to see if they would get an error.) I have a few thoughts.

1) Create a page where you can enter the link to an entry in your own journal (or your community), and the properties are displayed. This is simple and pretty straightforward, does not require monkeying around with any existing pages, but not entirely friendly.

2) Create a URL argument (like the ?view=flat that you can add after the entry in the address bar) to display it on/from the entry. This would be reasonably friendly, but would probably take a lot more developer doing, and you'd have to look up how to do it if you didn't remember and needed to use it. (Depending on what was less of a pain to develop, I would see this as either adding information to the existing display, or going to a new location containing the information and a link back to the regular view of the entry.)

3) Have a little link/toggle near the rest of the entry information (depending on which was less of a pain to develop as described above), labeled "advanced entry information" or similar, to make it discoverable by people who don't already know to look it up.


Questions about the advisability:

1) Is there enough need for this information that someone couldn't just go ask Support? Senior support could tell people better than I could how often they get requests that require entryprops information.

2) Would this answer more questions than it would cause? It would not be fair to Support to release a feature that would cause a deluge of "What's a ____ and why do ____???!?!" questions. If this is implemented, someone grab me and I will write docs.

3) Would any information be revealed that a community administrator shouldn't have?

4) Would any information be revealed that is Dreamwidth-internal and a user shouldn't have? (I doubt it, but I ask for completeness; staff would have to answer this one.)




Development: This sounds like the sort of high-complexity, low-impact project that might sit for 10 years without being claimed.

Poll #12339 View entryprops for your own journal/administrated community
Open to: Registered Users, detailed results viewable to: All, participants: 38


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (76.3%)

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

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