dw_suggestions | Entries tagged with workflow: customization

Title:
Customize: random, automatic rotation of 'Featured' styles

Area:
styles

Summary:
The styles featured in the 'Featured' category have been the same for ages. Implement something that will make them randomly and automatically rotate.

Description:
Rotation could be overridden when necessary.
Frequency could be once a month (more? less?).
Previously featured themes could not be featured again for X amount of time.

Edit: limit the number of themes from the same style you can display at the same time to 2 or 3.

Poll #2618 Customize: random, automatic rotation of 'Featured' styles

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (18.9%)

(Other: please comment)
0 (0.0%)

alisx

Title:
Support for @import and @font-face

Area:
styles

Summary:
Update the CSS cleaner to support modern CSS, including the @import and @font-face directives.

Description:
The current CSS cleaner is overly-restrictive in what directives it supports, which makes designing modern layouts unnecessarily difficult.

In particular, the @import and @font-face directives should be supported (at the current time they are stripped out). The former allows for clarity and organisation of code for designers (as well as the use of well-known frameworks and reset styles), while the latter is becoming a staple of "Web 2.0" design.

While care still needs to be taken to protect against malicious XSS attacks, the @import and @font-face directives in-and-of themselves wouldn't seem to be any more dangerous to users than, for example, background-url (which can also be used to import foreign data).

Poll #2513 Support for @import and @font-face

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (62.5%)

(Other: please comment)
0 (0.0%)

faevii

Title:
Option to Choose Placement of Metadata

Area:
entries, styles

Summary:
On the Customize Style page, include an option to pick whether you want the metadata to appear at the top or bottom of posts.

Description:
As far as I know, there isn't a single style that places metadata above the entry text right now, and I don't think there's an easy way to change that via CSS, either. I don't know if anyone else feels this way, but I prefer my metadata at the top because it already gives me an idea of what a post will be like before I start reading. For example, certain moods might warn me that a rant is coming or that the person isn't being serious. I'm sure there are situations in which the music or location can contain useful information as well.

Since I doubt it would be a good idea to make some styles one way and some the other, how about including an option to choose, just like we can already choose where the sidebar goes?

Poll #2342 Option to Choose Placement of Metadata

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (51.5%)

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

Shouldn't be implemented.
3 (9.1%)

(I have no opinion)
13 (39.4%)

(Other: please comment)
0 (0.0%)

rhi

Title:
Carry custom text through style changes

Area:
Styles

Summary:
When you change your style, it would be nice if your Custom Text carried over, the way your links list does.

Description:
When you change your style, your Custom Text doesn't carry over. Your Links List does, however. Would it be possible to designate Custom Text as a field which also carries over with your ID?

Poll #2193 Carry custom text through style changes

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.5%)

(I have no opinion)
2 (5.0%)

(Other: please comment)
0 (0.0%)

foxfirefey

Title:
Allow users to customize their navigation links

Area:
Styles

Summary:
Users should be able to specify which navigation links appear, and in what order.

Description:
Hiding a navigation link (usually network, for paid users) is one of the most popular recurring support requests. It would be better for users, and support people, if users were able to customize which navigation links through the style wizard.

Disadvantages of this mean that users might not have new navigation links show up when/if we add them (such as when we add media hosting), but considering this could break a layout for users with navigation links going horizontally, that's not necessarily a downside.

Advantages of this means that we might be able to give more navigation icon choices, even ones that aren't defaults, such as a link to "Icons".

Poll #2178 Allow users to customize their navigation links

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (8.3%)

(I have no opinion)
8 (22.2%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Styles: add CSS class when calendar is horizontal

Area:
styles

Summary:
Add CSS to the calendar so one can style it more easily when it's displayed horizontally.

Description:
What I said.

Poll #2127 Styles: add CSS class when calendar is horizontal

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (3.6%)

(I have no opinion)
9 (32.1%)

(Other: please comment)
0 (0.0%)

syderia

Title:
Favorite Tags in Tag Module

Area:
tags

Summary:
Giving users the possibility to display favorite tags in the tag module in the same way that they can display the most popular tags.

Description:
Currently, the tag module can display all of your tags or the n-th more popular tags, where you set n.

My issue with the "most popular tags" is they they don't necessarily reflect the current state of my journal.

Let's say that I used to write a lot of fanfiction about Show#1, but it doesn't interest me anymore, however, I am moving in the fandom for Show#2 and starting to write stories.
I might want the tags for these new stories to show up, and the tags for the stories on Show#1 to not display.

So what I'd like is the possibility for the user to chose to display the tags they want to display by picking them out.

Poll #1807 Favorite Tags in Tag Module

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.6%)

(I have no opinion)
12 (30.8%)

(Other: please comment)
0 (0.0%)

kaigou

Title:
Replace style-screenshot with Preview Button

Area:
customization, backend

Summary:
On the Select Journal / Customize theme pages, where it says "User's Current Theme", turn the image into a preview button for the user's own style.

Description:
Currently, the image is static and doesn't reflect any changes made in the Wizard, which renders it useless (and worse, potentially confusing) once a user's done any significant color/layout changes in the wizard. Also, there's no way to preview changes without going to a separate browser tag/window and reloading.

Retaining the layout/theme names but with a "preview your style" button makes editing a lot easier, because the user would only have to click on the button to get a pop-up screen (same method/function as when you preview potential styles before selection). This would also alleviate the impression that even when one's done a bunch of changes that one's style is still "what's in that picture".

[Possible add'l benefit of implementation but NOT necessarily part of this suggestion, just something to consider: removing the image could allow for three-column setup in that top-most section, with the left column staying as-is, and the middle column listing layout, theme, and the preview button, and the final column listing the additional options. This (I hope) might also reduce the height of that top-section, which would save a lot of time for smaller-screen users who otherwise have to page-down to get back to the page's content, after every save/reload.]

Poll #1744 Replace style-screenshot with Preview Button

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (4.3%)

(I have no opinion)
6 (26.1%)

(Other: please comment)
0 (0.0%)

kaigou

Title:
Amend help-language in Style Wizard

Area:
styles, wizard

Summary:
Amend the help text in the Style Wizard to say "Leave blank for default."

Description:
Currently when you're customizing your style in the Wizard, there are several places (most notably the font size and family selections) where you'll see help text that says: "Leave blank if you don't care." This isn't just non-helpful, it also reads as a little rude.

If you didn't care, then you probably wouldn't be mucking around in the style wizard in the first place. Beyond that, it doesn't actually tell you what happens if you leave the entry blank. It doesn't help either when the default version is a blank input box.

Frex, many styles give you the option to pick fonts for text, title, sub-title, post title, but the input boxes are empty. Too many scary questions for new users: what font's being used, then? Or does the style use my browser's default? Will the style will break in some way that I might've prevented had I cared enough to enter a font-name into the input box?

It's not a perfect solution (I'd prefer all wizarded-styles with default values reflect these in any input boxes), but at minimum changing any instance of "leave blank if you don't care" to "leave blank to use default" at least lets the user know there *is* a default (of some sort) that will be applied in the absence of user selection.

Poll #1724 Amend help-language in Style Wizard

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (38.1%)

(Other: please comment)
0 (0.0%)

allchildren

Title:
Preserve journal style/app style preference

Area:
Styles

Summary:
When user changes journal themes, the journal style checkbox "Show entry pages in my journal style rather than the app style" is reset, with the app style defaulting into place. I propose that the user's previously stated preference be preserved throughout theme changes.

Description:
DW users choose styles: Tropospherical, Celerity, etc. They also choose whether to view those styles on entry/comment pages or to view comment pages in the style of the journal theme, aka app style, by checking or not checking the box marked "Show entry pages in my journal style rather than the app style." (I find this language very vague and confusing since everywhere else on the site "theme" is prevalent over the term "app style," but that's probably another suggestion.) However, every time the user changes journal theme, that box resets itself and site display defaults back to entry/comment pages in the app style.

My philosophy is that once a user has checked a box to state a preference, that preference should remain unless specifically changed. Particularly during the current development of new themes, I am interested in trying out new themes, and to have my preference for entry pages displaying in Celerity undone is incredibly annoying. Since journal style and theme are different things that are controlled on different areas of the site, it makes no sense that this single style preference should be tied to theme changes. At the very least, the journal/app box should be made more obvious in relation to theme changes, if it must be reset every time the user changes their theme.

The main drawback I can think of is that users changing theme may expect their entry pages to follow suit regardless of their previous preference. I think many users may not be aware of the journal/app style checkbox at all, so possibly that needs some better publicity or language. My alternate suggestion is to move the journal/app style checkbox to the theme page so it is more convenient for the user to re-check the box rather than go to a different page entirely.

Poll #1316 Preserve journal style/app style preference

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (88.0%)

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

Shouldn't be implemented.
1 (4.0%)

(I have no opinion)
1 (4.0%)

(Other: please comment)
1 (4.0%)

ninetydegrees

Title:
Subscriptions filters: create a module for them

Area:
S2, layouts

Summary:
Create a module that would display subscriptions, the way navigation links or custom links can be displayed.

Description:
As some people may have a lot of filters, either set a limit or let people display the first x ones (like for tags).

Edit: see Turlough's suggestion for making this module optionally private.

Poll #1247 Subscriptions filters: create a module for them

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (22.2%)

(Other: please comment)
1 (3.7%)

starwatcher

Title:
Different colors for different types of links

Area:
Links in Styles

Summary:
When customizing, we can select a color for links, but I'd love to select different colors for 'name-links' on my reading page, links in the message, and the 'go-to' links at the bottom of the post. (Edit, reply, etc).

Description:
Problem to be solved - I don't think there is 'a problem'; it's just an aesthetic I'd like to see.

When playing with colors, I'd like to be able to choose one color for title links (the ones at the head of our post), a different color for linked names (the people who have commented), another color for links in my post, and a separate color for the tiny 'go-to' links at the bottom of the post.

I'd also like a 'visited link' color for each of those options. I *don't* want my title-links to change color when I've clicked on them. If we had choices of colors for each type of link, we could select the same color for visited links in the areas we choose. As it is, when I select a 'visited link' color, I have to choose between all my links always remaining the same color, or my title links changing color when visited. Neither of those solutions make me completely happy.

Drawbacks to implementation - I can tell it's a helluva lot of coding. My coding expertise ends at italics, bold, and <a href, so I don't even know if it's possible. But it would be nice if it could be considered, somewhere down the line.
.

Poll #1192 Different colors for different types of links

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
13 (43.3%)

(I have no opinion)
11 (36.7%)

(Other: please comment)
2 (6.7%)

cesy

Title:
Quick way to view all styles

Area:
styles

Summary:
Add a page with a list of all "base" styles, with links to the filtered pages of all colour themes with that base style.

Description:
On http://www.dreamwidth.org/customize/ there are now a fair number of styles, and there will be more soon. I know there is a plan to split them into sensible categories eventually. However, this feature would still be useful even when there are categories.

If you click on the name of the style - e.g. for "Green Basic Boxes by branchandroot", if you click on "Basic Boxes" - you see all the styles with that base and different colour themes. This is quite useful.

What I'd like to see, is a quick way of finding out a list of all the different bases, with a link for each one to that filtered page of different colour themes for each base. For instance, a quick glance now shows me "Basic Boxes", "Boxes and Borders", "Stepping Stones", "Modish", "Transmogrified", "Negatives", "Zesty", "Drifting", "ColorSide", "Blanket" and "Tabula Rasa", but I don't know if that's all of them or if there are some other base styles I haven't looked at.

(I'm not sure if "base" is the right term, but I hope it's clear what I mean.)

Poll #1154 Quick way to view all styles

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.6%)

(I have no opinion)
5 (12.8%)

(Other: please comment)
0 (0.0%)

zvi

Title:
Style wizard saves user layer properties in alphabetical order

Area:
styles

Summary:
The styles wizard should save the user layer properties in alphabetical order. This will make the layer easier to deal with if a human should wish to amend or examine it.

Description:
I imagine that the first toe tip a person puts into manipulating the styles system will be at the user layer level, either manipulating it directly or examining it for insight into how the styles system works. (An easy way to create a theme layer, for instance, is to choose all the settings in the style wizard and then copy the relevant portions to a new theme layer. Finding the relevant portions is very hard, though.)

Currently, the human readability of the file is hampered because it's very difficult to figure out whether a particular property exists in the file or where it might be in the file if it is there.

While alphabetical is not generally the ideal way to organize a large amount of hierarchical data, the styles team has done an excellent job of naming properties in core2. Alphabetization will lend a reasonable proxy for ontology, and, if new properties are added, they will slot into the existing properties in a comprehensible way.

The first potential drawback is that it might be expensive to make the wizard do this.

The second drawback is that it may encourage people to manipulate their user layers in the layer editor and lose their customizations when they change something via the wizard. This is (a) frustrating and (b) impossible to reverse.

Poll #1082 Style wizard saves user layer properties in alphabetical order

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (65.0%)

(Other: please comment)
0 (0.0%)

zvi

Title:
Add link to advanced layer area from layer editor

Area:
styles

Summary:
Add link to advanced layer area from layer editor.

Description:
http://www.dreamwidth.org/customize/advanced/layeredit?####### links to the S2 documentation, but not to the rest of the site. After one has applied the changes to their layer, you have to go back in history to get back to any other Dreamwidth pages.

I propose adding a link to the site-schemed page from which one has most recently come, http://www.dreamwidth.org/customize/advanced/layers You can use regular site navigation from that page to get where you need to go, but it's better than using the history function (and posssibly accidently saving an old version of the layer. D:)

Poll #1044 Add link to advanced layer area from layer editor

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
27 (84.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (15.6%)

(Other: please comment)
0 (0.0%)

zvi

Title:
Add additional color specifications for anchor tags in Transmogrified

Area:
styles

Summary:
There are link color areas in Transmogrified which are not controlled through the wizard color options, but only via CSS. These links should be brought under wizard control.

Description:
The way the Transmogrified wizard currently works, color is only defined for links in the entries/comments, modules, header, and footer. Links which appear anywhere else use the browser's default, which is unpredictable and may result in completely invisible color combos.

The wizard should be changed for greater control. The simplest solution is to define the anchor and anchor visited colors for the whole page (probably next to where one chooses "page text color".)

Alternately, more wizard controls for the text in more places could be added, although there may be a negative trade-off because too many choices are overwhelming.

Anchor tags not controlled by the wizard, listed by 900degrees http://getting-started.dreamwidth.org/42407.html
.navigation .inner a (The forward/backward links at the top of the journal)
.page-tags .tags-container .ljtaglist a (the tags on the tags page)
.page-tags .manage-tags-link a (the manage tags link on the tags page)
.page-entry .bottomcomment a (the navigation at the bottom of an entry page)
.page-archive .month .footer .inner a; .page-archive .month .day-has-entries a; .page-month .month dt a; .page-month .month .entry-title a; .page-month .month .tag a (various links on the archive and month views)

Poll #1021 Add additional color specifications for anchor tags in Transmogrified

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
27 (79.4%)

Should be implemented with changes.
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (20.6%)

(Other: please comment)
0 (0.0%)

ratcreature

Title:
check the basic syntax of the custom CSS when saving

Area:
styles

Summary:
It would be neat if on the Customize Journal Style page the field for "use embedded CSS" would check whether the CSS syntax is valid, i.e. whether all brackets and semicolons etc are there, and alert you if the CSS was invalid before saving.

Description:
When I put in "Custom CSS" (mostly just to change small things like having the icon on the left rather than the right and such) I test the CSS first in only my browser (usually with the FF Stylish extension) and check it there and then c&p it in the field. Sometimes without noticing my c&p misses a starting . or a closing } or such, I save and then am confused that it doesn't work.

It would be useful if the input form could alert me if the CSS was invalid right away. It would be even more awesome if the CSS field had a preview option showing how the custom CSS I entered will change my journal, because then I wouldn't need to use the Stylish extension to try out the CSS at all.

Poll #1012 check the basic syntax of the custom CSS when saving

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (53.1%)

Should be implemented with changes.
7 (21.9%)

Shouldn't be implemented.
2 (6.2%)

(I have no opinion)
6 (18.8%)

(Other: please comment)
0 (0.0%)

zvi

Title:
Better names/access to auto-generated user layers

Area:
Styles

Summary:
Make it easier to

(1) better distinguish between auto-generated user layers
(2) know when you're generating a new user layer as opposed to saving over an earlier one
(3) switch back to a previous auto-generated user layer without going to the advanced customization area

Description:
I know just enough about the style system that I (a) like to mess with settings in the wizard [including extensive CSS] and (b) can put an entire style together.

But I can't put styles together without leaving the regular customizations area. Using just the wizard, it's impossible to, for instance, save for the future my current very pink version of Transmogrified, but, for the moment, change things with colors/CSS/images done in the wizard (i.e. the user layer) to make a dark style. Because, once I get tired of my dark Transmogrified, I can't, via the wizard, go back to my fluffy pink version.

I know that I can do the saving with the "Your Layers" part of the advanced customization area and the switching with the "Your Styles" part. However, figuring out which user layer interests me is made unnecessarily difficult by the fact that all of the auto-generated user layers are named Auto-generated Customizations.

I propose that
(a) the 'layerinfo "name"' property gets added to the wizard.
(b) "save", "new blank customizations", and "copy current customizations to new style" buttons get added to the wizard
(c) a method for selecting user layer gets added to the /customize/ area.

Benefits of this is that it will let people have better control over their styles without them poking in the advanced customization area or having to learn the difference between a user layer, a theme layer, or a style layer.

It will let users change styles more easily, without worrying that if they make changes they dislike they won't be able to go back exactly to what they liked before.

It may add fewer random autogenerated layers to the system.

The disadvantage is that it makes selecting a style, even with the wizard, more complex than it currently is. I can't really think of other drawbacks.

Poll #1011 Better names/access to auto-generated user layers

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes.
3 (12.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (20.0%)

(Other: please comment)
1 (4.0%)

kaigou

Title:
Accessible Layouts

Area:
Identifying accessible layouts

Summary:
It'd be good to make it easier on folks with vision issues (or who use handhelds) so they can quickly and easily find layouts suited to their purposes.

Description:
I presume eventually DW will follow LJ's path of having provided layouts tagged (seasonal, colorful, minimal, etc). I think there needs to be a tag for users with vision issues, so they can quickly and easily find layouts that are usable with screen readers, screen magnifiers, even handheld devices. (The latter two work best with single-column layouts.)

The same tag, or an overlapping tag (meaning some layouts would qualify as both), would sort out the high-contrast or reverse layouts (stark white on black, stark white on wordperfect blue). Then another tag for layouts with default fonts greater than 14px, and a tag for low-contrast layouts, for users who actually *get* vision problems from too many high-contrast designs.

So there's the categories: vision-accessible, high contrast, low contrast, single-column, and large-font. If I were really dreaming, I'd suggest DW contact its user-comm for blind/vision-impaired users and invite them to be panelists/judges for reviewing/nominating which layouts are "screen-reader-friendly" versus "screen-magnifier-friendly". That way, layouts with that designation really are tested as being good for those purposes, and not just because a good-vision person (like me) says it looks like it satisfies the basic requirements.

(For more info and a great example of designing vision-friendly, see the BBC's info pages on accessible layouts: http://www.bbc.co.uk/accessibility/. It's a wealth of information.)

Poll #998 Accessible Layouts

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
42 (89.4%)

Should be implemented with changes.
2 (4.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (6.4%)

(Other: please comment)
0 (0.0%)

jesse_the_k

Title:
Modify Layout of Page to Edit Linkslist

Area:
http://www.dreamwidth.org/customize/options.bml?authas=jesse_the_k&group=linkslist

Summary:
The text boxes which determine the order of links barely show two digits: expand horizontally to comfortable show four places.

Description:
I hope it's an easy fix!

Poll #881

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes.
0 (0.0%)

Shouldn't be implemented.
4 (28.6%)

(Other: please comment)
2 (14.3%)

Dreamwidth Suggestions

Customize: random, automatic rotation of 'Featured' styles

Support for @import and @font-face

Option to Choose Placement of Metadata

Carry custom text through style changes

Allow users to customize their navigation links

Styles: add CSS class when calendar is horizontal

Favorite Tags in Tag Module

Replace style-screenshot with Preview Button

Amend help-language in Style Wizard

Preserve journal style/app style preference

Subscriptions filters: create a module for them

Different colors for different types of links

Quick way to view all styles

Style wizard saves user layer properties in alphabetical order

Add link to advanced layer area from layer editor

Add additional color specifications for anchor tags in Transmogrified

check the basic syntax of the custom CSS when saving

Better names/access to auto-generated user layers

Accessible Layouts

Modify Layout of Page to Edit Linkslist

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate