Sections - Contents and Naming

[Heather Floyd]

To add to the discussion posed by Niels about wording for the names of the sections (http://www.youtube.com/watch?v=eHjGBydBnr0 - 35 mins in)...

I was thinking that perhaps it would make sense to think about the sections according to developer/editor roles and reorganize the "Settings" section contents.

Content - this is pretty good - used by writers/editors

Media - also pretty clear, used by writers/editors and some graphic designers (uploading images)

Users - Being a long-time user of umbraco, I understand the difference between "Users" and "Members", but the distinction might not be too clear for newbies. This section is used by the umbraco Admins - those who manage the people who can access the system - permissions, etc... Perhaps a different name would make it clearer, but I don't have an idea for one now...

Members - maybe a slight modification to "Website Members" would make it clearer that these people deal with the "front-end" website - not the back-end admin interface... but if you want to keep it to a single word, I think "Members" is fine.

Settings - I think the main issue I have with this "catch-all" name is that the things available for editing in this section are not really grouped logically - which explains the generic name.
I would suggest that we think in terms of developer roles, like "front-end" development, and "back-end" development.

Perhaps the section could be called "Design" or "Interface" and include only the sections "Stylesheets", "Templates", and "Scripts". In a larger design shop, permissions could be given to front-end devs and graphic designers for this section.

I think that "Media Types" & "Document Types" should only be accessible to changes by Information Architects or back-end developers. This would suggest that those two areas be added to either the current "Developer" section, or to a new "Architecture" section.

I also feel that "Dictionary" and "Languages" should be part of the "Architecture", and the "Dictionary" needs to be hooked into the "Translation" system somehow - I noticed that you can't "Send for translation" Dictionary items, which seems like it should be possible.

Developer - perhaps renamed "Development" or "Code", since otherwise it is the only section which is named as a person, rather than a thing.

Anyway, I look forward to a lively discussion from other umbraco-loving IAs out there. :-)

~ Heather

[Anthony Candaele]

Op dinsdag 6 november 2012 20:27:51 UTC+1 schreef Anthony Candaele het volgende:

Hi Heather,

This is a nice kickstart for giving the BackOffice sections some better names. I think the main criterium should be that the name must be as close to the type of functionality that the section holds.

So I am all in to rename the section 'Developer' to 'Code'.

Architecture ... I don't know, it's better than 'Settings', but in essence what are Document Types, they are a means for structuring data, so why not just call this section 'Data Structure'?

I also think the replacement of 'Settings' by 'Interface' is a good idea. The Interface section holds the functionality 'Stylesheets', 'Templates' and 'Scripts'

Members - Users, although the labels accurately describe the functionality that's underneath, I also found it a bit confusing in the beginning. Less confusing terms could be 'Backoffice Users', 'Website Members'

greetings,

Anthony

Op dinsdag 6 november 2012 16:48:43 UTC+1 schreef Heather Floyd het volgende:

[Anthony Candaele]

Op dinsdag 6 november 2012 16:48:43 UTC+1 schreef Heather Floyd het volgende:

To add to the discussion posed by Niels about wording for the names of the sections (http://www.youtube.com/watch?v=eHjGBydBnr0 - 35 mins in)...

[Marc Goodson]

Yes main problem is 'Settings' being a catch-all and Users vs Members

hmm:

Content - Content

Media - Media

System - Users, Languages, Dictionary

Structure - DocTypes/MediaTypes, Packages

Design - Stylesheets, templates, scripts. new section for stylesheet referenced images

Code - the new name for dev less Packages.

Public - members or maybe members should just stay the same, think it is the presence of 'users' that confuses the meaning of 'members'

but maybe Languages/Dictionary should be in structure ?

Design is probably the wrong word, it should be UX or UI or interface, but people do still tend to call it 'the design' ie where does 'the design' stuff go...

it's not easy :-)

[Brendan Rice]

I was thinking along the same lines of diving the sections up into relevant sections for the personas. Niels said they identified 4 personas during research of people who use the Umbraco admin:

1. Editors

2. Programmers

3. Umbracans (spelling might be off but think Lee or Matt, shit term but power users)

4. Web Designers

Not sure if this will help splitting up the sections but thought it was relevant.

[Chris M]

Umbraco has a very non-confusing interface when compared to a lot of other CMS products out there, but for me when I was first learning how to use things, I'd get mixed up between Membership and Users, and also Settings and Developer.  Usually the issue came down to me knowing the tab that I was looking for within the section but not where the section was located.  I'm not entirely sure whether Belle would work with a 3-level heirarchy, but here's how I see the split of what's in the backoffice in 4:

• Website
• Content
  
• Media
  
• Membership
  
• I8n
• Languages
• Dictionary
• Translation
• Information (statistics and other useful website information)
• Audit logs
• Cache browser
• (3rd party stuff like analytics)
• Backoffice
• Content types
• Content types
• Media content types
• Design (stuff that affect output)
• Templates / Stylesheets / Scripts
• Scripting / XSLT / Macros
• Configuration (stuff that affects umbraco-wide configuration)
• Packages
• User types / permissions
• Membership types
• Data types
• Hostname management etc
• (Future config sections / third party settings)

Even when I've been working on larger sites, there tend to be the website people and the people who do everything else, so the grouping of the website related stuff is probably more important than the groupings around the other backoffice components.  Under this split, the 4 user types pretty much work out with editors sitting on the website category, programmers mostly working with the backoffice, web designers using both the website and design sections and Umbracans using a bit of everything.  

I realize that the above has some big problems (are content types actually configuration, that the users and their configuration [and members and their configuration] are split), but hopefully it has some useful thoughts on where things could sit.  Getting something that splits up the concerns nicely and allows admins to easily lock down user types would be really handy.

[Stephen Gay]

I like that one.
I like that the dictionary is in the front-end part.
Although the languages are more back-end to me.
Stephan

[tentonipete]

I like Chris M's divisions.

The one area where we have issues using Umbraco is how to give a "Power editor" access to things that affect the site but won't break it!  They shouldn't have access to tweak document types, templates or scripts. At the moment we create a new back office section for things like Dictionary and anything custom like Categorisation. I would imagine that things like workflow administration would go here too.

This "power editor" kind of user is something we come across on most of our projects and I don't think is covered by the 4 personae documented above.

I don't know whether this something that came up in the Mark Boulton report?

[Martin Griffiths]

What version of Umbraco is Belle slated for?

In the issue tracker for version 6, I put forward the following suggestion (Although I think Chris M's suggestions are on the money!)

Developer:

Cache browser (could argue this one for either section, but in most cases only devs would be interested in this)

Scripting files (can we not just call this Razor files?)

XSLT files

StyleSheet files

Script files

Template files

Settings:

Media types

Data types

Document types

Relation types

Macros (as long as this item is held in the Umbraco DB it should be here)

Languages

Dictionary

Packages

Of all the remaining settings Macro's may be better suited to a config file due to their very close relationship to developer code. This would allow an Umbraco developer to do a more complete file based deployment without having to poke at the Umbraco database.

[Ravi Motha]

Of all the solutions I have worked on been working on this might be the best stab at a organisational structure that will allow it to last a long time (plus all my naming was rubbish).

While it is focussed on 4 user types I think it works for more than that. Th only thing to think about is where we have group users with only a single section  and rather than having to navigate they are directly presented with that option

eg user a is  only allowed to dictionary, they shouldn't have to go through l8n

On Wednesday, November 7, 2012 1:28:42 AM UTC, Chris M wrote: