[META] Terminology improvements #127
Comments
jenlampton
changed the title
jenlampton
changed the title
|
I love where you are going with blocks and layouts! The only issue I have with this list is "Content types" to "Page types". Everything else is something I've had to explain to new Drupal users. We use node types for a lot of content that doesn't fit the concept of "page". Having the explain that something is called a page even though it isn't just a page because it generates a display when a specific URL is called seems just as wrong. The fact that you didn't even carry the Content -> Page transition though to "page/add" vs. "content/add" makes me feel like Page is too specific. Less thought out... consider Taxonomy -> Categorizations. Instead of creating a Taxonomy, you'd be creating a Categorization then adding Categories to it. Think Jeopardy. When selecting US Presidents for $1000, most people won't describe US Presidents as a term in a category. It IS the category with questions "in" the category. Categorization (Jeopardy) > Category (US Presidents) > Content (Question) People think of "tagging" as something very specific, but most people understand defining a "system" for Categorization by defining the Categories they will be "putting content into". |
|
In backdrop, people won't be using nodes for things that aren't pages. This is what you are doing in D7, but because you need to mis-use nodes because we don't have a suitable non-page node thing. In Backdrop, If you are creating a testimonial, a slider item, or anything else that doesn't need its own path, you should be using a block type and not a node type. Thus, all nodes become pages, and node types become page types. Blocks are also content. Using node/add only works for nodes (pages) and it wouldn't make sense to list block types on the page/add page. Worse, would be to create a block/add page and a category/add page too. They should all appear on a single content/add page. Thus, content/add - a place where you can add Page types, Block types, and whatever else! |
|
I feel like "Appearance" could be changed to "Themes". It seems like appearance is used for describing what the Themes are instead of just saying here is the Themes page. "Appearance" links to your theme settings page and so does "Themes" so that is at least redundant, if not intentional. |
|
@clickbox This was an intentional change in D7 for UX improvement. The average person-on-the-street doesn't know what the word "themes" means, but they do know what "Appearance" means. We want them to say "yes, appearence, I want that" and then stumble onto the themes page. That's training them to know what themes are. By providing both links, you also meet the needs for people who know what themes are. We did the same thing to the Functionality/modules links in Backdrop - since this appearance/themes change was so successful. |
|
That makes sense. You can change the name of it in the menu settings too I suppose, if you have a personal preference. |
|
Perhaps these issues can be added to the |
ghost
added
the
jenlampton
changed the title
I want to propose some improvements for Backdrop's UI. Below is a list of ideas I'd like to run by a larger group for consensus. I'm summarizing here so people can get the big picture.
Product-wide Terminology Updates
Product-wide terminology updates will replace one term, globally, with another. This involves User Interfaces, URLs, Code, and Documentation.
Front pagetoHome pagein core #2162 | ChangeFront pagetoHome pagein coreMenu Clean Up
Admin Bar Updates
Toolbar-only changes serve to help get users to the pages they are looking for more easily, but do not attempt to rename concepts from Drupal.
The text was updated successfully, but these errors were encountered: