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

Title:
Styles: make it easy to list your IDs on other websites in profile module

Area:
modules, interoperability

Summary:
Dreamwidth displays links to other sites on your profile page but not on your journal. I suggest adding picture links to your other accounts (Facebook, Twitter, Instagram, etc.) to the profile module (or to another module if that's a better idea).

Description:
The idea is that you could enter your usernames on other sites and Dreamwidth would automatically create the appropriate picture links to the other accounts using the correct logos and display them into your profile module. This can already be done manually in the custom text module but I don't see why it shouldn't be easier to do. This is a pretty standard feature on several major websites now and I feel it's missing on DW. Ideally this could be further automated by using the 'other sites' part of your profile page and a simple option such as 'show links to other sites as filled out on my profile'. However, this part of our profiles is missing major sites such as Facebook, Instagram and YouTube so that would limit the usefulness of this new feature imo.

Poll #18045 Styles: make it easy to list your IDs on other websites in profile module
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.0%)

(I have no opinion)
9 (22.5%)

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

stormy: βͺ ππŽπ“πˆπ‚π„ ❫ 𝑫𝑢 𝑡𝑢𝑻 𝑻𝑨𝑲𝑬 𝑴𝒀 𝑰π‘ͺ𝑢𝑡𝑺 ⊘ (Default)
[personal profile] stormy

Title:
[css] Add admin-post css to entry-wrappers.

Area:
styles, entries

Summary:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others.

Description:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others. Personally, I'd love to use this as a way to call more attention to those specific entries without having to use a .poster class and have everything marked by a specific user stand out.

An additional suggestion related to this: At current the class .admin-post gets added to comments when they are made official moderator comments. It might be easier to suggest this css is changed to .admin-comment if it is a comment and .admin-post if it is added to an entry. This isn't a necessary step because you could format with ( .entry-wrapper .admin-post AND .comment-wrapper .admin-post ) but it might just be cleaner for those who don't like listing multiple classes together to specify.

Poll #14085 [css] Add admin-post css to entry-wrappers.
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (32.4%)

(Other: please comment)
0 (0.0%)

equationhouse: - (Default)
[personal profile] equationhouse

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

Area:
tags

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

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

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

Poll #12621 Having the option of tags appearing at the TOP of entries
This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.2%)

(I have no opinion)
15 (32.6%)

(Other: please comment)
2 (4.3%)

[personal profile] swaldman

Title:
New feature: style layer gallery

Area:
Styles

Summary:
It would be very nifty to have a "gallery" of not full styles/layouts, but little "snippet" layers that tweak one feature.

Description:
DW has a huge amount of customizability thanks to the Styles system. However, this is inaccessible to most as they (we!) do not have the technical knowhow to write style layers. Even those who do know what they're doing probably reinvent the wheel from time to time.

I suggest a gallery of "snippet" layers that modify or tweak one specific thing. Users can submit layers (whether directly or via developers in the same way as themes, I'm not sure) and other users can apply them to their journals.

This approach would allow a great deal of customization of how things are displayed for those who want it - even non-technical users who can't write their own S2 - without cluttering the UI with endless choices and tickboxes.

From a quick look through recent dw_suggestions, here are examples of recent suggestions that I think would be nicely implemented as little layers of this sort:
http://dw-suggestions.dreamwidth.org/1383840.html
http://dw-suggestions.dreamwidth.org/1383840.html?thread=4348320#cmt4348320
http://dw-suggestions.dreamwidth.org/1378835.html

Possible drawbacks:
- People breaking their journals by applying poorly-coded layers
- Layers that conflict
- Other interaction problems, probably
- Difficulties for Support from all of the above
- Might increase pressure on the maximum number of layers that people can use
- If there is some screening / manual adding of snippets, then time of people who do this
- Probably other stuff ;-)

It'd be a major enhancement, so would have Impacts... I don't pretend to be able to forsee them all :-)

Poll #11812 New feature: style layer gallery
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
14 (33.3%)

(I have no opinion)
17 (40.5%)

(Other: please comment)
1 (2.4%)

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

Title:
Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag

Area:
Styles

Summary:
Currently the post view that shows your entries organized by tag (for example: http://marahmarie.dreamwidth.org/tag/book+reviews) has the same body class as the front page of our journals, that is, it uses the .page-recent body class. I'd like to suggest that we add a body class specifically for the entries-organized-by-tag view, so that it gets the new body class .page-tag (not to be confused with .page-tags, which is currently in use on the Visible Tags page, the one that simply lists all your tags on one page).

Description:
As a casual (but slightly obsessed) DW CSS designer, I'm often confounded by not being able to style every page view on DW individually. Because we have a sorting feature on our DWs that lets users browse full posts by each tag used on them, I want to style those pages to work as well and look as good as all the other pages on our DWs do. But the front pages of our journals and the tag views of our posts? They share the same HTML body class (.page-recent), which means tag views can be sort of weird-looking because they inherit .page-recent's styling, which often does not work on the tags view of our posts for an assortment of reasons. Which makes me think: why not just add a new, separate body class so we can style those pages, too? I humbly suggest we add the body class .page-tag to all views on our DWs that sort posts by the tags used on them (for example: http://marahmarie.dreamwidth.org/tag/book+reviews would get the new .page-tag body class, as would all other similar page views on our DWs).

Poll #11750 Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.7%)

(I have no opinion)
17 (43.6%)

(Other: please comment)
1 (2.6%)

zvi: self-portrait: short, fat, black dyke in bunny slippers (Default)
[personal profile] zvi

Title:
Remove Zesty from List of Official Styles

Area:
styles

Summary:
Remove Zesty from list of official styles

Description:
Zesty is a style that was rushed into being an official style because the first official style only had a black theme. While that first style ¿Negatives? was cleaned up to fit into the style guidelines, Zesty has never been revisited. It lacks many of the features of Dreamwidth styles: multiple column configurations, the editor is different, the placement of elements within an entry is different (which may be more of a feature than a bug), the CSS is different (making it difficult to manipulate for style designers). To be blunt, the only way in which it is a Dreamwidth official style is that it is available to choose from the official style interface.

Until/unless some noble style designer takes on the challenge of getting zesty to conform to the normal features of an official Dreamwidth style, let's remove it so that all style guides and style announcements can be written without the asterisk *except for Zesty.

(I assume that making it unofficial will not remove the style from Dreamwidth, i.e. anyone who currently has Zesty selected as their style should still have it, it's still a public style, it just won't be in the style chooser.)

Poll #11551 Remove Zesty from List of Official Styles
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (14.3%)

(I have no opinion)
21 (37.5%)

(Other: please comment)
2 (3.6%)

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

Title:
Styles: make is possible to have the navigation links at the top in most styles

Area:
styles

Summary:
Currently, only a few styles let you have the navigation links at the top (i.e. above or in the header). I suggest that this becomes a standard option whenever possible so that people who find this more convenient can easily choose to have them there.

Description:
Being able to have the navigation links at the top is one of the main reasons I'll pick a style over another one, sometimes even my very first criterion (particularly for communities). If I can have this as an option in many different styles, it leaves me with more styles to choose from.

As for above or below journal titles: whatever's easiest to implement and looks best.

Edit: rephrased for better clarity.

Poll #9803 Styles: make having the navigation links at the top a default option
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (10.5%)

(I have no opinion)
19 (33.3%)

(Other: please comment)
0 (0.0%)

pacific_rain_acim: (Default)
[personal profile] pacific_rain_acim

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

Area:
Journal Entry Page of journals

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

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

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

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

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

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

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

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

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

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

Poll #9497 "Order View" button enabling viewers to see entries in EITHER oldest first OR newest first
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (10.7%)

(I have no opinion)
21 (37.5%)

(Other: please comment)
1 (1.8%)

little_terror: (Default)
[personal profile] little_terror

Title:
Fluid width content on entry pages

Area:
styles, entries, usability

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

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

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

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

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

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
20 (39.2%)

(I have no opinion)
13 (25.5%)

(Other: please comment)
3 (5.9%)

timeasmymeasure: kerry washington with a rose held right below her lips (Default)
[personal profile] timeasmymeasure

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

Area:
communities, customization

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

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

Poll #9397 Be Able To Customize "Member Posts" Text In Communities
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
19 (31.7%)

(Other: please comment)
0 (0.0%)

roximonoxide: (Default)
[personal profile] roximonoxide

Title:
Editable Module Headers

Area:
styles / customization

Summary:
User input fields to control the text headers of all modules, not just the custom text module.

Description:
Currently, the the Custom Text module allows for the user to change the module heading from the Text customization options for your journal. (The same page where you might edit other default page text such as metadata labels and navigation links). Though you can hide module headers entirely with css, other modules have no such customization options other than order and page placement. It would be exceedingly helpful to both users and communities who use their journals, and the modules available to them, differently if all other modules allowed for the user to alter the default module headings to text of their own choosing.

This might logically be implemented either from the Text page, as it already exists for the with the Custom Text module, or from the Modules page where order and organization of your modules takes place.

Poll #9210 Editable Module Headers
Open to: Registered Users, detailed results viewable to: All, participants: 68


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (2.9%)

(I have no opinion)
26 (38.2%)

(Other: please comment)
0 (0.0%)

cmshaw: DC Comics: Kory cries "X'Hal!" (Default)
[personal profile] cmshaw

Title:
Keywords are not listed separately for styling the icons page in S2

Area:
styles

Summary:
In the S2 code for the IconsPage, there is an array of icons which contains the user's icons (as Icon objects) listed in the order specified. Each Icon object has an array containing the icon's keywords. When the IconsPage's sort order is the order in which the icons were uploaded, each Icon object has exactly one element in that array no matter how many keywords the icon has, and that one element contains all of the icon's keywords concatenated together.

Instead of this, the array should have one element per keyword, with each element containing one keyword.

Description:
The IconsPage styling was implemented last year (http://dw-styles.dreamwidth.org/18631.html) but it hasn't been used much; all of the system styles are still using the old icons page.

Here is the code from the core2 which concerns itself with the icon keywords:

    if ($.keywords) {
        """<div class="keywords">""";
        var int keyword_count = 0;
        print safe "<span class='label'>$*text_icons_keywords</span> ";
        """<ul>""";
        foreach var string kw ($.keywords) {
            $keyword_count++;
            """<li>""";
            print safe $kw;
            if ($keyword_count < size $.keywords) { print $*text_icons_keyword_sep; }
            """</li>""";
        }
        """</ul></div>""";
    }


This, to me, pretty strongly implies that the keywords array was intended at some point to hold multiple elements which should be looped through in order to display each keyword separately. There's a string to hold the separator between the elements and everything! I would like it to hold each keyword in a separate element here, when the icons have multiple keywords to be displayed; I think it makes a lot more sense than forcing a comma concatenation in a one-element array.

(Side note: when the sort order is by keyword, the icons appear multiple times in the $.icons array, each time with just the applicable keyword in their $.keywords array, which seems fine to me. I am not suggesting changing the behavior for the keyword-sorted icons.)

Poll #8384 Keywords are not listed separately for styling the icons page in S2
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
31 (77.5%)

(Other: please comment)
0 (0.0%)


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

Title:
Profile module: match text links with icon links

Area:
styles

Summary:
In the Profile sidebar module of official styles, you can choose to display the interaction links (subscribe, track, post, search, etc.) as icons or text. Some icon links and their alt text are more precise than text, which makes text links less useful in my opinion. I wish they matched.

Description:
For example, there's a 'join community' icon and a 'leave community' icon with corresponding alt text. If you switch to text you get 'Membership' in both cases. It would be nice if the text could change according to the viewer's status like it does for icons.

[If you're using an official style and want to see what I mean for yourself, you can switch to text at http://www.dreamwidth.org/customize/options. It's the option called 'Select whether user interaction links are printed as text or using the available icons '.]

Poll #7885 Profile module: match text links with icon links
Open to: Registered Users, detailed results viewable to: All, participants: 51


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (23.5%)

(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:
Option to display snippets of most-recent entry comments on reading page

Area:
reading page, comments, styles

Summary:
Allow for styles to display snippets (with context) of most recent visible comments to an entry on the reading page. It might show a small version of the comment's icon, the username, "in reply to [a comment by <username> | the entry]", the timestamp, and the raw or markup-stripped first ~255 characters.

Description:
The ability to read comments without leaving the reading page would probably be at least as powerful as the ability to expand cut tags from the reading page. I believe it would lower the barriers to interaction and entice people who would not have otherwise interacted into interacting, rather than enabling the laziness of readers and allowing readers who would have otherwise read all the comments to skip over them. It would be impractical to load a whole page of comments (complete with threading) on the reading page, however. Two or three to ten or fifteen might be reasonable.

This would be a choice made by the reader in turning on the option for their reading page style, and would not show them anything that they wouldn't be able to see by opening any entry in ?view=flat and looking at the last page of comments, so if it were implemented, it would be difficult to justify allowing a journal owner to disallow comments from their entry to be loaded on the reader's reading page. (If a journal owner had recent-comments view turned on in their own journal and a reader wanted to turn it off, ?style=mine and ?format=light both should turn it off.) People who rely on Google Analytics to track readership numbers for their specific entries might feel as though this cheats them out of page views, if there is no technical solution to track this (for readers who are not blocking Google Analytics code, which can be done easily).

The suggested form represents a compromise between loading all the comments and loading none of them, with aspects drawn from independently hosted blogs, Twitter and some of its clients, Facebook, and YouTube.

I suggest most-recent comments as the ones to display, because the first comment may not even be useful, replied-to comments can't be edited and won't change, and the only way the first comments are going to change is if they're edited or one is deleted. I suggest snippets because Dreamwidth comments can be very long. I suggest raw or markup-stripped because when you're doing snippets, there's a danger of having markup that starts but doesn't end. If the comment is longer than the bit given, there should be a clear indication that it continues, a la the Latest Things page (which also cuts off long entries).

YouTube sorts by most-recent first and allows the viewer to flip between pages of comments inline, which is a neat trick. YouTube comments can also be a pit, and I don't know how much of that is attributable to the interface, how much is the commenting community, and how much is the broadcast attitude & not-much-moderation of the video creators.

It could be a latest-comments module that is turned on with a tickybox in the styles area, and further stuff could be customized either with controls there or as advanced editing. Things like number of comments, icon display, icon size, format of timestamp, size of text, minimum/maximum height of the area given to each comment (maybe a fixed height and scroll bars would be a good idea), perhaps maximum number of characters to display (again, very long comments are possible) might be good settings to have.

I don't know if data like the username of the parent comment is a thing that is stored to be easily fetched, or whether it would have to be expensively derived each time. If it would have to be expensively derived, a regular parent link could be used. (Something really shiny from Twitter would be displaying context of the parent comment inline when clicked, if the parent is visible to the reader.)

Inline ability to reply to the comment would only be advisable if the whole comment were displayed, and even then I find it questionable. However, there are or were ways to add inline top-level commenting to LJ friends pages (not sure if it's possible on Dreamwidth) and I did not see much difference between those comments and other top-level comments. It's also possible to get comment notifications, and reply to comments that one gets the notifications for without reading any of the other comments to the entry.

Poll #7714 Option to display snippets of most-recent entry comments on reading page
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (17.0%)

(I have no opinion)
17 (36.2%)

(Other: please comment)
1 (2.1%)

ciaan: revolution (Default)
[personal profile] ciaan

Title:
Memories Icon Different If Post Already Memoried

Area:
memories, entry pages

Summary:
In the site style, the "add to memories" button on an entry is a heart with a plus mark over it. It would be nice if, when the entry was already in your memories, this button changed in appearance to something slightly different, and the alt text changed to "edit memory."

Description:
I'm not sure what the new icon should be, though.

Poll #7557 Memories Icon Different If Post Already Memoried
Open to: Registered Users, detailed results viewable to: All, participants: 71


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (9.9%)

(Other: please comment)
0 (0.0%)

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

Title:
Include entry subject line in Take a look at this Dreamwidth entry

Area:
site: email

Summary:
Include the Dreamwidth entry's own subject line in the Take a look at this Dreamwidth entry e-mail's subject.

Description:
I'd like to see (even part of) the Dreamwidth entry's own subject line in the Take a look at this Dreamwidth entry e-mail's subject. "Take a look at this Dreamwidth entry" is rather generic especially when one gets more than one.

Poll #7127 Include entry subject line in Take a look at this Dreamwidth entry
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
34 (64.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (30.2%)

(Other: please comment)
0 (0.0%)

ivorygates: (Default)
[personal profile] ivorygates

Title:
Include Name of Journal Base Style and Theme In Credit Module in Journal

Area:
Styles

Summary:
By default, journal styles credit the designer or designers of the base style and the theme and display that information in one of the modules. What does not appear is the name of the base style or of the theme being used by the journal. It would be nice if that information also displayed.

Description:
When I read a journal displayed in the owner's style, there are many times when I would like to know what base style and what theme they have chosen. While there is a default module that appears in the journal [unless you select to remove it] that displays the names of the people who created the base style and the theme, neither the base style name nor the theme name is displayed in the module [at least in any of the journals I've looked at]. This is frustrating if you see a style/theme you think you'd really like and have to do a lot of trial and error on the "Select Journal Style" page to try to find it, and it would be nice if there were an option to display this information by default.

Since some people write their own style from scratch, or tweak the theme, or use their own resources for background images, it would probably also be nice if the module that displayed full style and color credits could automatically default to "Base style: DesignerName; Theme: JournalOwner; Resources: Journal Owner" in that case.

Poll #7105 Include Name of Journal Base Style and Theme In Credit Module in Journal
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)
1 (2.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (25.5%)

(Other: please comment)
0 (0.0%)

allen: (Default)
[personal profile] allen

Title:
Add an HTML5/CSS3 (core) style

Area:
styles

Summary:
We should put in a style, be it a customized style or a core style (core5?), that generates HTML5 code and uses CSS3 features. Since this wouldn't be universally supported, we should also available only on a beta/opt-in basis at first.

Description:
Ok, HTML5 isn't actually an official standard yet, but the latest versions of the major browsers support significant sections of it. Same with the various parts of CSS3 and WAI-ARIA. And while we wouldn't want to force everyone to upgrade their browsers, it would be nice for users and developers to have the option of trying out the new features.

In particular, I'd suggest that we build a single S2 layer that generates valid, semantically correct HTML5. We'd probably also need to update the Javascript on the pages to work with the new structure. We could even do a single page at a time, falling back on the default style if the HTML5 version of the page isn't available. This would give us time to standardize the page structures, accessibility requirements, etc., without having to worry about getting a working version of everything done.

Beta opt-in could be through the <a href = "http://www.dreamwidth.org/betafeatures">beta features</a> page. Only users who had opted in would see the new HTML5 pages. To make it simple, we'd probably want to have that value sticky everywhere, so that if you chose to see HTML5, you'd see it on all pages where it was available by default. (Though style=light or style=mine would probably still be available as an override.)

Poll #6688 Add an HTML5/CSS3 (core) style
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.3%)

(I have no opinion)
22 (46.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 an Optimized-for-small-screens category to the Select Journal Style page

Area:
styles, accessibility

Summary:
Test each theme as presented in the Select Journal Style area for how well it behaves on small screens. Put the ones that work well into a category, so people who need this can find them easily. Meta-task: identify accessibility situations with distinct needs, and create theme groups specifically for them.

Description:
This is apropos of a support request where someone had decided against using Dreamwidth because it did not work well for them on a small screen out of the box. Foxfirefey put a good amount of research into finding themes and styles that worked well with small screens. This seems like a situation that will probably come up again, and not every person showing frustration will think to come to Support.

The meta-task, of identifying accessibility situations and creating theme groups for each of those (for example: small screens, light sensitivity/migraines, large font...) sounds as though it would work well paired with FAQs targeted at those same needs from a whole-site-usability standpoint: how to set site skin, where to find and change themes, etc.

Poll #6571 Add an Optimized-for-small-screens category to the Select Journal Style page
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (5.3%)

(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