ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees
Lightboxes are a bad idea so I've submitted a new suggestion to improve our current preview pop-ups. Please comment on this one instead once it's approved. :)

Title:
Have previews load on same page in small pop-ups

Area:
entries, comments

Summary:
We have wonderful magic for Quick Reply and a nice pop-up for browsing icons. I'm thinking that something along these would be nice for previews too. So no more loading the preview in the same tab (like DW does for comments) or even loading it in a new window (like DW does for entries). Just a small pop-up you could post your entry and comment from if you're happy with what you see or with a link to go back to the editing page, which would close the pop-up (it is currently not possible to post an entry from its preview page or go back to editing from there; you can only close the window). This type of previews is already implemented on several sites.

Description:
On the Comments preview page, there is additional info (such as which HTML tags are allowed). I think this info should be accessible before you click preview (I don't see how you're supposed to know you have to click on preview to get it in the first place). It could be via a ? button or a text link.

Feel free to suggest better implementation! There may be even better preview magic I haven't seen yet :)

Poll #18018 Have previews load on same page in small pop-ups
Open to: Registered Users, detailed results viewable to: All, participants: 29


This suggestion:

View Answers

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

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

Shouldn't be implemented.
14 (48.3%)

(I have no opinion)
9 (31.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 : 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%)

style_tester: this is a pink rose (Default)
[personal profile] style_tester

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


This suggestion:

View Answers

Should be implemented as-is.
31 (73.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (11.9%)

(Other: please comment)
0 (0.0%)

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

Title:
Give Us The Ability to Delete Junk Data and Spam From Polls

Area:
Polls/Entries

Summary:
Someone just spammed/trolled/junk data'd my poll at http://www.dreamwidth.org/poll/?id=17242. I'm not sure why anyone would do so, and of course we have zero power over what people post as answers in the polls. But if we at least had the power to either delete unwanted data or report it and have it deleted by Dreamwidth staff, this would be immensely helpful.

Description:
I've only ever posted a few polls and the most recent one is the first to suffer from a junk data problem from an anonymous user who used my poll's various text fields to 1) spam, 2) write in junk data and 3) otherwise trample upon the spirit and intention of my poll. Of course as soon as I saw what this user had done I looked for a way to remove their input but was unable to do so.

I'm not sure why anyone would spam and otherwise post junk answers in a poll. But if we at least had the power to either delete unwanted data, or else report it and have it deleted by Dreamwidth staff, this would be immensely helpful.

Poll #18015 Give Us The Ability to Delete Junk Data and Spam From Polls
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (22.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:
Customize Style: randomize 'featured' styles automatically

Area:
ui, styles

Summary:
If I'm not mistaken, the featured section was originally meant to showcase new styles. As this requires manual updates and, consequently, hasn't ever been really reliable I suggest switching to an automatically randomized selection. This way you get a diverse selection showcasing different styles, colors, etc. and there's no need to take one's precious time to do it. I also suggest restricting it to 12 styles only.

Description:
If an automatic way to select brand new styles and themes is just as easy to do as making the selection automatically random then I'm all for keeping it (or having both). I just wish this section actually served a purpose...

Poll #18014 Customize Style: randomize 'featured' styles automatically
Open to: Registered Users, detailed results viewable to: All, participants: 33


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (3.0%)

(I have no opinion)
12 (36.4%)

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

zaluzianskya: (Default)
[personal profile] zaluzianskya

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

Area:
Comments

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

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

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

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (9.1%)

(I have no opinion)
11 (33.3%)

(Other: please comment)
1 (3.0%)

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
Poor [site community profile] dw_suggestions. It hasn't been as dead as it looks (I've been moving things directly into the issue tracker all along for little changes that don't need discussion), but the queue got out of hand again despite my best intentions, and then (of course) it became A Thing where I couldn't just do one or two things from the middle without first handling all the stuff that had been waiting forever with profuse apologies so I just looked at the whole thing and went "ugh" and went away to go put my limited work time elsewhere. *

* My native slacker avoidant tendencies have been sharply exascerbated over the past few years due to chronic pain, depression issues, and untreated-up-until-now ADHD... yes, this is why news posts have also been few and far between in the past year and a half.

Anyway, HOORAY FOR MEDS (seriously, hooray for meds), and I will be working to catch up on the queue over the next few days/weeks. This means:

* There will be some old entries posted to the comm for discussion. When they're posted, please remember that the person who made the suggestion may have done so a very long time ago and wasn't necessarily expecting it to be posted now, or that things may have changed on DW or elsewhere on the internet since the suggestion was made. If there are any suggestions where things have changed on DW since it was originally written, I'll leave a note in a comment on the suggestion. Please read comments before voting and/or leaving a comment of your own!

* If you submitted a suggestion a while ago and it wasn't ever posted or rejected, you will be getting a posting or rejection notice sometime within the next few days. I'm sorry it's taken so long.

* Many suggestions have been sitting in the queue because they won't work for one reason or another, but they really deserve a thoughtful, detailed response explaining why it wouldn't be possible or why we've considered it or something like it in the past and decided that we didn't want to do it. A big part of why I got behind was that I do like to give those thoughtful, detailed responses when I reject a suggestion -- if you took the time to write the suggestion, you deserve me taking the time to explain to you why it wouldn't work -- and that takes a lot of time, brain, and typing that I haven't reliably been able to summon recently. In the interests of cleaning out the backlog and getting current on things, though, I'm going to give myself permission to be a little less carefully detailed and thoughtful when I reject the older suggestions. If my explanations are too simple or you want to know more detail, you can email me at denise@dreamwidth.org. (Just include the rejection notice so I can be reminded what I wrote -- I'm writing a bunch of them today!)

tl;dr: SUGGESTIONS QUEUE BEING CLEANED OUT. SITE ADMIN VERY SORRY. SITE ADMIN MEDICATING BRAIN PROBLEMS NOW. (Site admin has given up on body problems ever getting totally fixed, but at least has drugs for that, too.)
alierak: (Default)
[personal profile] alierak

Title:
Improve OpenID claiming

Area:
OpenID

Summary:
Claiming your OpenID may help with future imports that bring over your comments, but there are other areas it does not cover.

Description:
We have a mechanism where a DW user can "claim" an OpenID identity (e.g., an LJ account that has been used to post comments elsewhere on DW). That records the claim in a table and kicks off a job to change ownership of all the OpenID identity's previous posts. Thereafter, if an import of some other journal is going to bring over comments owned by that user on the remote site (which would normally be shown using their OpenID identity), ownership is changed to reflect the DW user during the import. However: - I don't think the claim relationship is shown anywhere in the DW profile or metadata for the OpenID userid. Perhaps the profile for that userid should just redirect to the claimant anyway, like a renamed user. - I think it's still possible for the user to log in and comment using OpenID, and then those new comments cannot be changed over to the DW user because that OpenID identity is already claimed. Like the importer, comment posting probably ought to check claimed_by first. - We don't update the circles of everyone who has trusted the OpenID identity. This could probably be done in the same worker that changes ownership of posts. These things are probably all unexpected behavior if you're migrating from another site to DW. Thoughts?

Poll #17823 Improve OpenID claiming
Open to: Registered Users, detailed results viewable to: All, participants: 17


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (5.9%)

(I have no opinion)
8 (47.1%)

(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:
Expiration warning for feed account comments sections

Area:
feeds

Summary:
Display a notice in the comments section of feed accounts about the 14 day expiration of the entry. This would serve as a reminder that all things are ephemeral, and if the user wanted their comment saved, they could go to the original (settings allowing) or manually save it somewhere.

Description:
There's been some previous discussion around comments on feed accounts. Currently, comments are enabled on feed accounts as a courtesy to Dreamwidth users who would like a forum, however ephemeral, to discuss the feed amongst themselves, particularly when the source does not allow comments (such as XKCD).

However, it's not immediately obvious to someone who is unfamiliar with feed accounts that the comments won't be sent back to the original source of the feed, and that the comments will vanish when the feed entries vanish after 14 days.

I suggest a notice, to be displayed on the entry page above the comments section (so it's visible to readers and to people using quickreply), and on the reply page. It would say something like: Only feed entries from the last 14 days are displayed on Dreamwidth. Comments left on feed entries will not be saved after the entry is gone.

(People using quickerreply from their reading pages probably wouldn't have that notice visible.)

Users would be given enough information to decide for themselves whether to try to leave their comment on the source, or whether it's more appropriate for the comments on the feed. It could feel unnecessary or annoying to users who are already aware, and would introduce another little delay for screen reader users to try to skip over.


(If implemented cleverly, this could possibly be reused to support comment policy notices for communities and personal journals.)

Poll #16990 Expiration warning for feed account comments sections
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.6%)

(Other: please comment)
0 (0.0%)

Apologies

Jul. 11th, 2015 12:56 am
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
As people have probably noticed, [site community profile] dw_suggestions has been really quiet for a while. I've been having health problems (over and above the usual) for a while now and have had to really prioritize my DW work to get it in the time that I had available, and the suggestions queue perpetually fell down to the bottom of the list. (And then of course it got to the point where I was so behind that catching up required way more work than if I'd just done it at the time, which is always the way.)

At any rate, I have now caught up on the queue, and I'll do what I can to try to stay on top of it better. I'm really sorry.
omnipotent: (Default)
[personal profile] omnipotent

Title:
Random Icon Chooser for Quick Reply

Area:
Entries, Friends Lists

Summary:
The random icon chooser was a nifty feature that allowed one to utilize all their icons. However, it is not available via the "Quick Reply" option on one's reading page.

Description:
The summary pretty much describes it, but I was just curious if there are any plans to add the random icon chooser as an option while replying to an entry without leaving the Reading Page. Currently, to access the chooser, I have to leave the Reading page by clicking "More Options". Unfortunately, when I do this, if I have typed anything in the comment box, it is erased! That's genuinely the only reason I'm asking; it sucks to write a well-thought out comment, want to choose an icon and be able to see which icon I'm choosing, and then lose the text!

Poll #16840 Random Icon Chooser for Quick Reply
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.1%)

(I have no opinion)
14 (33.3%)

(Other: please comment)
0 (0.0%)

woggy: A frog, probably of South American vintage (Default)
[personal profile] woggy

Title:
Allow Markdown in site-based comments

Area:
Comments

Summary:
Expand markdown support to cover all areas of user input - comments currently may only use markdown if they are posted by email.

Description:
Markdown is a cool thing! We can use it (or not) in entries, and post-by-email comments are always using it, but there's no way to use Markdown in comments made directly on the site. This is a thing that we ought to be able to do.

Poll #16839 Allow Markdown in site-based comments
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
13 (27.7%)

(Other: please comment)
0 (0.0%)

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

Title:
Icon description length.

Area:
Icon descriptions.

Summary:
Increasing the length of the icon description.

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

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.7%)

(I have no opinion)
15 (34.9%)

(Other: please comment)
0 (0.0%)

lannamichaels: Astronaut Dale Gardner holds up For Sale sign after EVA. (Default)
[personal profile] lannamichaels

Title:
Add "modify this tracking" to tracking e-mails

Area:
Notifications

Summary:
When you subscribe to something such as "all new entries to a community" or "all entries tracked $thing", have a link at the bottom of the notification e-mail to modify/delete that notification.

Description:
When you subscribe to something such as "all new entries to a community" or "all entries tracked $thing", have a link at the bottom of the notification e-mail to modify/delete that notification.

Poll #16837 Add "modify this tracking" to tracking e-mails
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.4%)

(I have no opinion)
13 (31.0%)

(Other: please comment)
0 (0.0%)

zaluzianskya: (Default)
[personal profile] zaluzianskya

Title:
Add ability to add a Memory without leaving the page

Area:
memories

Summary:
Adding an entry to Memories is complicated. It should be easier.

Description:
What I propose is, when you click on the heart button to add an entry to your Memories, a box could pop up on the page for you to select a title and the labels for the Memory. If your browser doesn't support this, the code can degrade gracefully by taking you to the Add Memory page that currently exists.

This would make it less of a hassle to add Memories, since right now you have to go to another page, add the Memory, and then it takes you to a page that lists a bunch of other options like "go back to the entry", "view all your memorable entries", etc. Too many clicks, in my opinion.

Poll #16836 Add ability to add a Memory without leaving the page
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (35.7%)

(Other: please comment)
2 (4.8%)

[personal profile] swaldman

Title:
Allow Twitter OAuth identification instead of OpenID for commenting

Area:
openID (sort of)

Summary:
Allow Twitter OAuth identification instead of OpenID for commenting

Description:
A lot of my readers these days don't come from LJ or Dreamwidth, may not have an OpenID, or even if they do have one (most likely Google) don't know what an OpenID is. But most of them have a Twitter account. It would be nice if Twitter OAuth could be used as an identity for commenting. Possibly other OAuth providers too.

Poll #16835 Allow Twitter OAuth identification instead of OpenID for commenting
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.5%)

(I have no opinion)
6 (13.0%)

(Other: please comment)
0 (0.0%)

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

Title:
Add complete pre-filled custom s2 template for beginners on the Wiki.

Area:
Styles

Summary:
Add a complete, pre-filled custom s2 template on the Wiki for Dreamwidth s2 beginners that anyone can edit to add more example code as desired, to help users help themselves to more customized code without necessarily having to ask for help in one of the style communities or hunt down the exact page containing the code they want in the Wiki.

Description:
Ever wonder how to add something not given to you out of the box on your Dreamwidth journal, like an extra row of links in your DW's header or a second custom text box in your sidebar? So have I. The answer is you need a custom theme layer to add Dreamwidth's s2 code to - and you need to know or else figure out the right chunks of s2 code to add to it. By adding the right chunks of code you can make different things on your journal like the extra custom text box or basically almost anything that won't automatically be stripped out by the s2 compiler.

For the most part, if I have a question about how to write the correct code to pull off one of my latest ideas, I'll ask for expert help over in our style_system community and most of the time I'll receive excellent answers and help with all of the code wrangling needed. But not everyone is willing to wait on asking others for help and/or learning to any extent how the code works (or why it doesn't); they just want the shiny and to teach themselves the code for it (or ask for help in learning it) as they go along - maybe later, or maybe never.

The question in one's mind at this juncture may be, "Why should there be this big code hurdle for me to jump just to get at some of the shiny"?

So my suggestion toward this is based on our s2 Cookbook which is kept here: http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook

My idea is to keep the separate pages we already have on the wiki for adding modules (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Modules), making the heading work as a link (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Linking_the_title_on_your_journal_to_your_main_journal_page) and so on, and to add more pages for other similar functions as needed, but to also add a new page that shows all of that code and more working together at once, starting from the opening lines (which are generally something like, "layerinfo "type" = "theme"; layerinfo "name" = "layer name";") for a sort of One Stop Shop where you can choose which bits of code you want for what or compile the entire thing to see how it all works and looks together at once.

With the code properly commented, it will be easy to see if any part of the code does what you need it to do and by reading the code under each comment you might get a sense of how it's doing what it does. For anything beyond that you can always still ask in the style communities for extra help.

Maybe this new Wiki page could be called "All known custom s2 functions adapted by our users - on one page!" and could be found under the "S2 Cookbook: Other Examples" heading, and be clearly marked as an example of how much each journal can be modified to do more interesting things and offer more interesting features. Anyone could contribute to it, so say if you learned in one of the style communities how to add extra previous and next links beyond what a standard DW offers out of the box (http://style-system.dreamwidth.org/108697.html), you could add the finalized code on that page to this new Wiki (besides giving it its own page on the Wiki like a few other functions already have) so others can see it as part of a complete example custom theme layer.

Poll #16807 Add complete pre-filled custom s2 template for beginners on the Wiki.
Open to: Registered Users, detailed results viewable to: All, participants: 24


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (37.5%)

(Other: please comment)
1 (4.2%)

rosefox: Green books on library shelves. (Default)
[personal profile] rosefox

Title:
Crosspost to TinyLetter

Area:
crossposting

Summary:
Add TinyLetter to the available crosspost options.

Description:
TinyLetter creates newsletters that are basically blog entries, but in addition to being posted on the TinyLetter site, they're emailed to subscribers. TL users get a few basic MailChimp tools like tracking opens and clicks.

Enabling crossposting from DW to TL would be a relatively easy way for DW users to permit non-DW users to sign up for emailed updates of DW posts. It would also give DW users access to those MailChimp tools, which can be handy.

The TinyLetter web interface is quite straightforward: you get a subject line and a message body, and that's it. The message body permits formatting. TL also accepts posts via email. This would probably be the simplest way to crosspost from DW to TL: send the DW post as a formatted email to the user's unique TL post-by-email address. Here's what the TL FAQ says about that:

"To publish through your private address, create a message in your own email client to send to the address. Format and design it however you like, and be sure to include a subject line. When you're ready, just hit send. We'll create a new draft in your account and send a confirmation email as soon as it's done. After the draft is created you'll be able to log in to TinyLetter to review and send your message. Or, you can reply to the confirmation email we send once the email is beamed in. To send the message directly from your email client, simply reply to the confirmation message, keeping the subject line and address field intact, and we'll send out that newsletter to your list of subscribers."

So the user would need to confirm via email, but it's still faster and easier than copying and pasting a post from DW to TL.

If there's a TL API, there's no mention of it on their website, but one might exist.

Possible advanced feature: only crossposting posts that have the "tinyletter" tag.

Poll #16806 Crosspost to TinyLetter
Open to: Registered Users, detailed results viewable to: All, participants: 30


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (3.3%)

(I have no opinion)
19 (63.3%)

(Other: please comment)
0 (0.0%)

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

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