New Create Entries management page

[denise]

This post is to report bugs in the new Create Entries page. This is a complete rewrite of the old Update page, in order to allow for future expansion and new features such as draft posts, scheduled posts, recurring posts, expanding the range of what can be posted to your journal, and a whole host of other awesome things.

When reporting bugs, please include:

* The browser name, browser version number, and operating system you're using
* The steps you took to reproduce the problem
* Whether or not you've tested the same steps in another browser (and if so, which)
* Whether you get the same result every time you try the same steps, or if it only happens sometimes

If we can't reproduce the problem under the same browser and operating system, we may also ask you for a list of any browser extensions you have installed.

Not all features are completely implemented in the new Create Entries page yet. The biggest thing currently missing is the Rich Text editor -- the only option is the plain-old-HTML option. The design of the page is geared towards changing concepts and visual/workflow metaphors around what it means to "post an entry", too -- because of the forthcoming draft and scheduled posts, we needed to adapt some of the language and some of the ways we present concepts -- even though the draft and scheduled post functionality isn't ready to be released yet. So, if something looks awkward or like it doesn't quite fit, it's probably there to allow for something we'll be releasing in the future. (You can still mention it, though!)

Things we also consider to be bugs that should be reported, in addition to something not working right:

* if you can't figure out what to do at any step of the update process
* if you have accessibility-related problems (with your screenreader, with the tab order of the page, with the workflow, etc)
* if something about the new workflow completely breaks the way you use your journal, and you can't figure out any way to work around it (there may be a way to do what you're used to doing, but if you can't figure it out, that's something we might change or might want to document, etc)

You can enable or disable beta testing at any point.

Not yet enabled

* Rich Text editing
* Using the new Create Entries page for editing existing entries
* Using the new Create Entries page for comm admins deleting posts or performing admin overrides
* Draft posts of any type, including the in-browser saved drafts that exist right now

Known/Reported Bugs

* some difficulties crossposting, looks like possibly date-related? we're trying to figure it out.

Should be fixed

* Settings not properly saving when using the "gear" customize-this-page popup; some modules disappear
* Create Entries form being repeated after posting an entry
* Error in link to Beta Features at top of page
* Error messages when using new update page in older versions of Firefox
* Difficulties with IE (oh, IE)
* Errors with time being truncated
* inactive icons showing in the icon browser
* minsecurity of journal not reflecting properly in update form
* whole host of display glitches

Comments

[rosefox]

Changing my site skin from Lynx back to Tropospherical fixed it, but I selected Lynx as my site skin ages and ages ago, so I'm puzzled about why it was only just applied to the create entry page.

[denise]

Ahh, Lynx has had some patches in the last few code pushes that may have affected subtle elements of the page -- that's probably why I couldn't see the difference between now and how I remembered it, because I wasn't looking at it in Lynx! I'll check with the guy who did the conversion and see if that was a deliberate choice or not. (Part of the updates in the past few code pushes have been to pull "fancy" CSS and most Javascript out of the Lynx skin, because it's designed to be as minimalist as possible.)

EDIT: Yup, checked with The Frontend Guy™ and the change was part of the efforts to make sure that Lynx uses more of the browser default styling instead of overriding it. Previously we overrode the browser default; now it appears however your browser handles <fieldset> elements. If it really bugs you but you don't want to move away from using Lynx as your default site skin, you can bookmark any of these URLs to hit up just the update page in one of the other site skins:

https://www.dreamwidth.org/entry/new?usescheme=tropo-red
https://www.dreamwidth.org/entry/new?usescheme=tropo-purple
https://www.dreamwidth.org/entry/new?usescheme=celerity-local
https://www.dreamwidth.org/entry/new?usescheme=gradation-horizontal-local
https://www.dreamwidth.org/entry/new?usescheme=gradation-vertical-local

[roadrunnertwice]

Yup: this was a recent change, and it was intentional. Like denise said, we did a bunch of fixes on Lynx recently.

Slightly long story, but it went kind of like this:

• Lynx is supposed to use the browser's default styling for HTML elements whenever possible. (It's sometimes not 100% possible, but we try.)
• All site skins actually have two versions: "old" and "foundation."
• Old Lynx is good at being All Default, but foundation Lynx was ignoring its mandate and using excessive non-default CSS everywhere.
• People mostly didn't mind that, because the core pages mostly used old skins.
• Then the "updated Stuff" beta switched comment pages to use foundation skins, and we got feedback about how wrong foundation Lynx was.
• I gave foundation Lynx a de-make. (The PR on GitHub has some further explanation/discussion if you're curious.)

Anyway, what you're now seeing on those boxes is the raw browser default styling for <fieldset> elements.

Out of curiosity, what do you like about the Lynx style? Do you prefer browser-default styles in general, or is there a specific set of annoyances you're avoiding in the other site skins? (I'm occasionally pondering what a more customizable default skin could look like, so I'm interested in hearing peoples' takes on the current ones. The main things I'm aware of right now are that people want control over font sizes and colors.)