Umbraco UI improvements - request for feedback

[Morten Christensen]

Hi all,

There has been a lot of discussion about features intended for developers, but not much about the end users who are probably the ones who use the backoffice the most. So I would like to kick start a discussion about what can be done to improve the UI, so that it is more enjoyable, easier to use or simply bug free from an end users perspective. A lot of you most have talked with clients who have voiced frustrations about certain areas of the backoffice - maybe the Content Tree is not updating probably or maybe the fact that you have to Create a Media item and name it before you actually upload an image is an annoyance.

Please be as concrete as possible ;)

Best regards,

Morten Christensen

[Stephen Gay]

Native drag and drop moves in trees.
Persistent trees in dialogs.
What else?

[Niels Hartvig]

I'd love to see heavy improvements in the Richtext editor as it's the main tool of trade for end users:

1) Perfect paste from Word (most common usecase and this worked really well in Umbraco v1 (yes, the ASP Classic version!!!)
2) The stable implementation of inline macros from v5

3) Bugfixes, bugfixes, bugfixes, bugfixes and more bugfixes

I'd also like to see the ability to mark a document type as holding 'tabular data', this would:

1) Hide children in the tree (think news articles / blog for instance)

2) When you click the item you'd be presented with a *list* of children, which would be searchable, filterable and sortable

3) You might even have a pre filled "Create new Article / Blog post" form ready to use

An improved Media library would also be on the top of my list:

1) Research how people are working with Media (what's their workflow like when they have a need for media so we could speed up the process)

2) Quick upload of files (drag'n'drop style - don't need to write the name of the media before you upload)

3) Easy bulk/mass upload of files without plugins (I love Desktop Media Uploader, but not everyone are fortunate enough to be allowed to use AIR apps)

Finally I'd love for a more configurable dashboard for common tasks (provider based) where you could just drag a node to the dashboard and based on its type and your permissions you'd be presented with options like

1) Show a list of x number of children based on filters (think 'show me the *ten* latest articles in the category *yyxxx*')

2) Create a item of type article with these fields available (directly from dashboard that is)

3) Etc. (as it's provider based you could have plugins for this)

Oh, one last thing. Speed. How can we make the UI the fastest on the planet through small incremental updates (compress assets, combine css sprites, etc). There's loads to update client side with easy wins.

/n

On Monday, June 18, 2012 7:29:34 PM UTC+2, Morten Christensen wrote:

[Roel Snetselaar]

Isn't this something which was already done for v5 by Alex Morris? (@aexmo on twitter) This is a nice discussion, but maybe you don't want to 'invent' the same issues again?

I didn't get into v5, @Morten maybe someone can start by making a list of improvements which were done in v5 or planned for v5? Seems to me we want the same UI improvements for v4 now.

Regards,

Roel

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/kke8Oyjw1pUJ.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

[Niels Hartvig]

Hi Roel!

No. The UX project was put on hold in January, so it never got out of the (awesome) research phase. We're kick starting the UX project over the summer and Alex Morris is already working on a masterplan (that obviously includes full transparency and community involvement - think UXathons (just with a better name ;)) where UX, Designer and core people can meet and get things done (improved))

/n

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Morten Christensen]

Roel, 

Alex Morris (of Mark Boulton Design) hasn't started any work on UX yet - a survey has been conducted and personas described, but that is about it.

We have already made a list of about 40 items that could be ported from v5 to v4, but very few are improvements targeted at end users. The only ones I can think of are: optimized Trees, dynamic menus and updated TinyMCE, which is why I'm asking for feedback. There are a ton of sites already built on v4, so there must also be knowledge about what could be improved - without looking to v5.

- Morten Christensen

On Monday, June 18, 2012 8:54:28 PM UTC+2, Roel Snetselaar wrote:

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Matthias Daun]

Independent of the kind of improvements the UI should keep its overall
clean look & feel.
This easiness at first sight is what every client really likes.

Additional improvements to the ones mentioned above could be:
- synthax highlighting in the html view of the richtext editor
- improved validation output (on the fly validation, form field
hightlighting,...).
- robust node sorting in trees (doesn't work in all situations right
now)

[Meixger]

My biggest wish would be a better preview function or ideally an integrated preview-browsing mode like N2CMS has

The left part of the backend shows the content tree and the right part shows the website (in an iframe)

Navigating in the website would sync the content tree.

Especially on big sites (several tousand pages) this allows my editors to easily switch from frontend to backend.

Try it on demo.n2cms.com user:admin pass:changem

[haug...@gmail.com]

A couple of suggestions:

* When a picture is selected using the Media Picker, show a thumbnail of the picture.

* Create a multiple file upload, using build-in browser capabilities (http://caniuse.com/#feat=forms), on a tab when a folder is selected in the media section

* Add an alt-text property to the default picture media-type, make the rich text editor use this for the alt text when inserting pictures

* Make the content tree navigable using arrow keys when it has focus

* Go through top aligned modal create dialogs, and make sure they don't need to be scrolled to get to the "Create" button. (at least the create member dialog does this)

I think several of these could be easy picks.

Regards
Jesper Hauge

On Monday, June 18, 2012 7:29:34 PM UTC+2, Morten Christensen wrote:
> Hi all,
>

> </div>
> There has been a lot of discussion about features intended for developers, but not much about the end users who are probably the ones who use the backoffice the most. So I would like to kick start a discussion about what can be done to improve the UI, so that it is more enjoyable, easier to use or simply bug free from an end users perspective. A lot of you most have talked with clients who have voiced frustrations about certain areas of the backoffice - maybe the Content Tree is not updating probably or maybe the fact that you have to Create a Media item and name it before you actually upload an image is an annoyance.</div>
> Please be as concrete as possible ;)</div>
>
> </div>
> Best regards,</div>
> Morten Christensen</div>

[Meixger]

seems Jeff Chapin had this running one year ago: watch his video http://www.youtube.com/watch?v=jsY_pl4MvgQ found on http://our.umbraco.org/forum/core/umbraco-5-general-discussion/13242-Composite-C1-CMS-is-very-like-Umbraco,-I-can't-believe-it?p=1#comment80740

[Michiel van Oosterhout]

I remember one of my co-workers first reactions to Umbraco: "are they planning to do a 'proper' UI anytime soon?"

The tree and editing area often end up in an inconsistent state. This would need to be documented first: what type of actions should have what types of consequences. Select a node, wait for its editing interface to load, and then delete the node: what should happen with the editing interface? Now it's possible in some circumstances to continue using the editing interface, including the save button. Naturally this will result in a ysod. 

Naming a file in the media section before uploading is obviously wrong, even if it's somewhat right for documents in the content section.

Parameter editing for macros can be improved, there's no room for complex editors or error messages. 

Can we move away from iframes and improve UI dialogs?

Every place in the UI should be reachable with a unique URL, including specific tabs for a specific document.

Agree with Niels about a node that has multiple items as its content, but not as child items in the tree.

[Michiel van Oosterhout]

On Monday, June 18, 2012 10:48:00 PM UTC+2, Meixger wrote:

seems Jeff Chapin had this running one year ago: watch his video http://www.youtube.com/watch?v=jsY_pl4MvgQ found on http://our.umbraco.org/forum/core/umbraco-5-general-discussion/13242-Composite-C1-CMS-is-very-like-Umbraco,-I-can't-believe-it?p=1#comment80740

Composite C1 does a lot of things right, although the UI is not 'pretty' it does have for example a much better experience for entering and editing macros.

[Michiel van Oosterhout]

Some other suggestions:

When there are no members, I get a list from A-Z, doesn't make sense.

Find a better solution for the need to store 'stuff' in the tree. Anything from carrousel items to widgets is stored as a tree node, but without a template. And then we 'solve' it by using some variant of multi-node tree picker to allow editors to choose these nodes to be displayed in a carrousel or sidebar. This only serves to make the UI more complex for editors.

[danny...@gmail.com]

Neils came up with a lot of suggestions I'd support.

Cleaning-up rich-text pasted into TinyMCE should be a must. I see so many sites visually ruined by content-editors who paste stuff from Word (or when migrating content from their old website). Even small stuff like <br> tags being insted instead of <p> causes problems.

Ability to set the default DocType that appears in the select list when creating a new page. At the moment it is alphabetical, with first item pre-selected. Imagine you create a new page and you have three DocTypes to chose from called Text Page, Sitemap and Contact Form - currently Contact Form would be pre-selected whereas Text Page is the one you would most commonly want.

New built in property umbracoDisableDeleted (True/False) that can be set to prevent a page (or media folder/item) being deleted. This is *essential* in many sites. Too often I've had clients delete the home page or other essential nodes by accident and panic. I know you can *kind of* achieve this with a custom event, but when you prevent deletion the node remains unpublished. Bake it into the framework so that when set the 'Delete' option never even appears in the menu.

Make moving page to new sections much easier. If you have to bulk move pages it is a pain. Drag'n'drop would help, but this has to be done carefully so as to avoid accidentally moving nodes.

A media picker like DAMP that is also in the RTE and works the same way.

Ensure content-tree refreshes after all events (including back-end API calls).

Easier ways to configure how child nodes are sorted after creation (ie. set the sort mode on the parent so, for instance, news items can be reverse date etc)

Be able to have a default Login page when creating a protected member area (this could be same as set in web.config). Having to pick the login page EVERY time (even though most sites only have one) is a pain.

Ability to paste in images to the RTE and have them auto-magically uploaded to a folder in the Media library. (So you could paste in a word doc with images).

[Gareth Evans]

I have a fairly substantial list to write up from several discussions at the retreat and CG12 and post into this thread.

Please keep the awesome suggestions coming but remember to be prepared to merge them into uTrack when it is available - it will be a huge job for one person to merge this thread into seperate issues for assigning/roadmap/development

Gareth

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/5Nvjg3oRsmMJ.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Dan Diplo]

Sorry, a couple more minor (but useful ones):

• There is currently a Label datatype for creating a read-only message, which is really useful for adding instructions/help to a tab group. However, it displays the "text" of the label squashed up in the left column rather than in the right-hand column, making it much less useful.
• Ability to add better help messages to all fields - perhaps an icon with a nice jQuery tooltip?

[Lee Kelleher]

For the Label data-type... not to always harp on about uComponents, we have one called Notes, (dev'd by Matt B), which offers RTE capabilities.  Could be a potential merge with Label?

http://ucomponents.codeplex.com/wikipage?title=Notes

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/piMGTn0gwUkJ.

[Dan Diplo]

On Tuesday, 19 June 2012 09:16:42 UTC+1, Lee Kelleher wrote:

For the Label data-type... not to always harp on about uComponents, we have one called Notes, (dev'd by Matt B), which offers RTE capabilities.  Could be a potential merge with Label?

http://ucomponents.codeplex.com/wikipage?title=Notes

Sounds perfect, and I would vote for this as to go in core to replace the (otherwise useless) label.

And whilst we are here another UI improvement - currently if you get logged out and then log-in again you are redirected to the inner-frame you were one and find yourself broken-out of the frameset with no obvious way to get back "in". 

[tim....@epiphanysolutions.co.uk]

I second the calls for improved Media Pickers in the CMS, the default one is a bit lacking, we pretty much use DAMP as standard now because of the extra features it offers.

For the media pickers elsewhere, it would be nice to be able to search for media items as well as use the tree, with big media libraries, it's a pain to navigate to images etc sometimes.

The RTE definitely needs some lovin'.

The switching between sections functionality is a bit flakey, sometimes it jumps to the right page, sometimes it doesn't. E.g. editing content, go to media, click back to content, and the tree shows the last selected thing in content, but the main page is still the media page you were looking at last, which confuses a lot of editors.

Have some way of showing in the members section when a letter doesn't have any members under it.

Make the permissions more like v5, that was one area of it I thought worked really well.

Fixing the preview mode is super important as well, currently you can't preview unpublished pages underneath an unpublished page (it 404s), and its very confusing for users trying to set up new sections on the site.

Build in Tom Fultons Structure Extensions package (or functionality like it). The ability to select a default child DocType for sections that have multiple allowed DocTypes is an absolute Godsend.

I'm sure I'll think of more!

:)

[Morten Bock Sørensen]

A comment on the Label datatype. It is in fact not useless at all. We use it to show values to the user, that we are setting through the API, but that they should not be able to edit. So in that case, when the data actually exists on the node, then it makes perfect sense, and the label should stay on the left side.

I think that is also what it was intended for, rather than an instructional field.

/Bock

[Adam Shallcross]

Check out Superpreview...it used to work, not sure if it still does...but i think this is worth upgrading and its a plan I always harped on to Tim (munkimagik) about.

Have a side by side view of the live page and the page currently being edited.

Without bringing up dirty words...Immediacy used to do this quite well :)

Cheers

[Morten Bock Sørensen]

On the subject of the rich text editor and macros, I would also like to see a nice built in solution to have macros inserted as non-block elements. That could be inserting keywords in the middle of a paragraph, or generating some sort of special links.

/Bock

[Michiel van Oosterhout]

+1

Stock symbols is an example

--

Sent from my mobile phone

On 19 jun. 2012, at 19:14, Morten Bock Sørensen <mor...@mortenbock.dk> wrote:

On the subject of the rich text editor and macros, I would also like to see a nice built in solution to have macros inserted as non-block elements. That could be inserting keywords in the middle of a paragraph, or generating some sort of special links.

/Bock

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/XAmw-bD8znMJ.

[Andrei C]

That is exactly how I use it as well, and I agree with that comment. I think that labels are very useful when it comes to storing data and making it so the user can't change it. 

As for UI feature requests, I would very much like to see drag-and-drop functionality for the content trees, a better way to upload media, and a complete removal of the alphabetization of users/members, if possible. Perhaps I'm missing something, but is there any reason why the parent letter nodes exist at all? 

Dan diplo and attack_monkey's suggestions are also things that I think would really improve the user experience.

[Ken Sykora]

The single biggest complaint I've gotten so far is the content picker doesn't allow you to restrict it to a specific sub directory of trees, or filter out specific types of content. It's a feature that Sitecore has and would be REALLY nice to have in Umbraco.

[Ken Sykora]

The rich text editor that's being used is also quite annoying. It'd be nice if you could develop a macro plugin for a different rich text editor, such as CKEditor, which is MUCH better than TinyMCE IMO.

On Monday, June 18, 2012 12:29:34 PM UTC-5, Morten Christensen wrote:

[simon.j...@gmail.com]

The media section needs an overhaul. I'd like to see multi-file uploading implemented natively. My clients and colleagues are complaining that the current way of naming and then uploading is too timeconsuming

If you add prevalues in the datatypes, you have to get it right the first time, as you can only create n' delete, not edit the labels.

[Sebastiaan Janssen]

@simon to be fair, there are a few multifile uploader packages, so they wouldn't need to complain if you'd installed one of them. ;)

That said, I do want some native support for that and easier creation of media files without having to name them as well. Been looking at jQuery file uploader, I just want to figure out which browsers are supported (no more flash or air, just html / jQuery)

On Jun 20, 2012 12:53 AM, <simon.j...@gmail.com> wrote:

The media section needs an overhaul. I'd like to see multi-file uploading implemented natively. My clients and colleagues are complaining that the current way of naming and then uploading is too timeconsuming

If you add prevalues in the datatypes, you have to get it right the first time, as you can only create n' delete, not edit the labels.

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/Aqc2pRdI6XYJ.

[mattbrailsford]

Whilst we are talking about the Media section, I did discuss at the retreat with a few people a new way to present the Media section that would lend itself nicely to drag and drop upload.

IMO the Media section just isn't fit for the task it aims to do, being more of a clone of the content section rather than really thinking about how people work with media. My suggestion was as follows:

1) Rename the concept of "Folders" to "Media Sets"

2) Limit the media tree to only display Media sets

3) Limit the media tree to only allow a single level (no nested Media Sets)

4) When you click on a Media Set display it's contents in the right hand panel (Use thumbnails and paging)

5) Instead of using sub folders for organisation, use tagging and smart filtering instead

IMO this would be much nicer to work with. Having Media Sets would allow us to limit Users access to certain assets, whilst using tagging and filtering will make it much easier to find assets rather than clicking through a thousand folders. By displaying assets in the right hand panel rather than the tree, and using paging will also help prevent death by a thousand tree nodes :) For uploads, we can then just do a smart detect of files being dragged into the right hand panel (think GMail) and have a much more integrated process.

What do people think?

(PS If we use Media Types for the Media Sets and Media Items, it should be technically possible to make it backwards compatable too. Just build it as a seperate tree, then enable / disable whichever you prefer)

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

[Richard Terris]

I find it hard to visualise what this would look like.

Not a bad idea to reorganise it but I quite like the sub-folder setup especially for bigger sites.

How about a screenshot type mock-up of how it would look? 

[Adam Shallcross]

Well, you could still have the folders on the right, but they'd be virtual folders i.e. wen you clicked on it they just performed a lucene search based on the tagging items?

This would then give you the best of both worlds.  The user could then maybe say what folders (virtual searches) he wanted to appear in the tree on the left, and save then as a favourite or the dev could pre-set them up?

makes it uber-flexible then for everyone.

Lucene should play a very bog part of all this and UX stuff I think...

Just saying :)

[Michiel van Oosterhout]

On Wed, Jun 20, 2012 at 9:52 AM, mattbrailsford <m...@mattbrailsford.com> wrote:

1) Rename the concept of "Folders" to "Media Sets"

2) Limit the media tree to only display Media sets

3) Limit the media tree to only allow a single level (no nested Media Sets)

4) When you click on a Media Set display it's contents in the right hand panel (Use thumbnails and paging)

5) Instead of using sub folders for organisation, use tagging and smart filtering instead

...

What do people think?

Sounds pretty good actually! What are the downsides?

I remember looking at Sitefinity and being impressed with its media section. It uses the main UI area to display thumbnails (organized in albums) and tagging to filter them. It extends this concept to videos as well. 

Screenshot: https://falafel.com/Libraries/Sitefinity_Modules/slider-album.sflb.ashx

What I liked about it was the intuitiveness, something that the current tree model in Umbraco really lacks (as well as the name first, then upload workflow).

[mattbrailsford]

A bit rough and ready, but along these lines:

https://dl.dropbox.com/u/138129/Media.png

On Wednesday, June 20, 2012 8:56:38 AM UTC+1, Richard Terris wrote:

[Adam Shallcross]

apologies for the bad english doh....I meant folders on the 'left', and 'big' part...basically replace the folder structure in the tree with some virtual searches...

cheers

[mattbrailsford]

I thought about the saved searches, so would agree with that, but I think the "psuedo" folder thing in the right hand panel might confuse people. Maybe then these can appear in the tree, either as child items of a media set, or within a different group, ie:

Media

- Media Sets

  - General

  - Press Releases

- Searches

  - My search 1

  - My search 2

On Wednesday, June 20, 2012 9:17:21 AM UTC+1, Adam Shallcross wrote:

[Richard Terris]

This is a great idea for us and looks good (your drawing talents are going to waste Matt ;) )

But playing devil's advocate, I've created sites for users in the past, and despite giving them some pretty intense training I still find them to struggle.

As an example, I had a client recently who had a massive e-commerce site and as you can imagine had a ton of images.

The trouble was that while the stuck (somewhat) to the tree structure for folders, they uploaded images with names such as 177283.jpg and didn't bother to actually name any images.

Tagging would be great and I'm sure we can train people to get in to this way of working - but - for some clients who are say a DIY wholesaler for example, they are often pretty IT illiterate ("we sell hammers, we don't know about this computer stuff") if they did upload the images without naming them properly, how would the filtering work?

[Adam Shallcross]

yeah, sorry i meant 'left' in the tree so it looks the same as now, but is just searches not 'actual' folders, so there are some default categories they have to choose for every item as a required field when uploading it so it at least has some categorisation, but with the option to add more if they need to.

[Niels Hartvig]

Love the idea, but still think you'd need to be able to have folders
in folders in the left pane. It requires no training to understand
that concept (and would be directly backwards compatible). You'd get

the best of both worlds.

Then we could also have easy upload in the right pane (just drop
images/files and they'd get uploaded (with the ability to update their
properties as the upload gets done (23hq.com's uploader does this in a
very nice way despite it's many years old).

>>>>>>> umbraco-dev...@googlegroups.com.

>>>>>>> For more options, visit this group at
>>>>>>> http://groups.google.com/group/umbraco-dev?hl=en.
>>>>>>>

> --
> You received this message because you are subscribed to the Google Groups
> "Umbraco development" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/umbraco-dev/-/FCfKI-y2arMJ.

>
> To post to this group, send email to umbra...@googlegroups.com.
> To unsubscribe from this group, send email to

> umbraco-dev...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/umbraco-dev?hl=en.

--

-


Kind regards,
Niels Hartvig

Chief Unicorn (founder)
Umbraco - the Friendly CMS

Lindholm Havnevej 31
DK-5800 Nyborg
Denmark

http://umbraco.org
Phone: +45 70 26 11 62

[Stephen Gay]

On Wednesday, June 20, 2012 10:58:17 AM UTC+2, Niels Hartvig wrote:

Love the idea, but still think you'd need to be able to have folders
in folders in the left pane. It requires no training to understand
that concept (and would be directly backwards compatible). You'd get
the best of both worlds.

One thing to keep in mind is running multiple-websites.

Currently, on the content side, that is quite easy. Assign permissions on site A to user A, and on site B to user B, and they can live in relative isolation.

As far as media is concerned, it gets more tricky. Our users want a "media root folder" per site, and they want to be restricted to their site's media root folder. We currently do it using folders, plus some handlers to filter out the unwanted folders from the tree, per user.

What I'm trying to say is, I guess, that one unique "media library" per Umbraco instance is not enough, and we need a way to structure it a little. And folders are quite useful for that. Unless someone comes up with a bright ideas to do it with tags, and assign permissions to tags?

[ma...@umbraco.dk]

That was what the Media Sets were for, so you could assign permissions to different users, but I see what you / Niels mean, so, maybe the middle ground would be that folders remain in the tree, but media items display in the right hand panel? The only thing I can think of that would hinder this would be the fact we don't currently have a concept of a "Folder" but rather we have media items that can contain sub media items, so it's whether we need some more explicit mechanism for defining what is a "folder" and therfore what should appear in the tree and what should appear in the right hand panel?

On Wednesday, June 20, 2012 10:17:11 AM UTC+1, Stephen Gay wrote:
> On Wednesday, June 20, 2012 10:58:17 AM UTC+2, Niels Hartvig wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Love the idea, but still think you&#39;d need to be able to have folders

>
> in folders in the left pane. It requires no training to understand
>

> that concept (and would be directly backwards compatible). You&#39;d get

>
> the best of both worlds.
>

> </blockquote>

>
> One thing to keep in mind is running multiple-websites.
>
> Currently, on the content side, that is quite easy. Assign permissions on site A to user A, and on site B to user B, and they can live in relative isolation.
>

> As far as media is concerned, it gets more tricky. Our users want a &quot;media root folder&quot; per site, and they want to be restricted to their site&#39;s media root folder. We currently do it using folders, plus some handlers to filter out the unwanted folders from the tree, per user.
>
> What I&#39;m trying to say is, I guess, that one unique &quot;media library&quot; per Umbraco instance is not enough, and we need a way to structure it a little. And folders are quite useful for that. Unless someone comes up with a bright ideas to do it with tags, and assign permissions to tags?</div>

[jbr...@gmail.com]

I created a topic on our a while ago. Might also have some nice suggestions for media: http://our.umbraco.org/forum/core/umbraco-5-general-discussion/26292-Umbraco-5-media-picker-features

[Niels Hartvig]

Make it simple in a just f****** do it attitude (now that we know what
the 'perfect architecture'): Hardcode (or put in a config file) the
default folder media type and bam - that's it IMHO. Problem if Umbraco
was your software engineering thesis - yes for sure. Problem IRL - not
at all :)

/n

> --
> You received this message because you are subscribed to the Google Groups "Umbraco development" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/ViLK1_hxDT4J.

[Chad Rosenthal]

I like the media set idea also. It would be great to have folders and then you add a media set to a folder. SInce the first thing I always do is:

Media

-- Images

-- Documents

It would also be great if, like the content section, that you could limit what goes into each media set.

The last thing is that it would be nice to finally create an html5 media type (I know that I can do this myself, and I do) that can allow you to upload 4 different videos to one media type. That way it can be backward compatible. MIght just need to make this a package. (although I think somebody already did).

-C

[Dan Diplo]

I agree you need to be able to nest folders (or "Media Sets") or whatever you call them.

It would also be nice if you could protect media items from access natively (I know there is a package for this) - maybe store them in /App_Data/ and write a handler to retrieve them? I know a lot of clients think that if they have a protected page that the media items on them are also protected.

I also think inheritance in Media Items is sorely underused, mainly because it doesn't work as well as Document Types (you can't copy, for instance). I like the idea of different Media Types for different content types - not just "Image" and "File". It means you can have nice icons, too, and custom properties per type (a lot of those properties could be generated from file meta-data). It also means you can limit what Media Items can be created under "folders", just like you can with Doc Types. That way you ensure only images can be created in an Images folder or PDFs in a PDF folder etc.

The ability to switch storage providers would be brilliant (a bit like Universal media picker) so you could chose to store your media library in the cloud (eg. Amazon S3) just by switching provider. People could write custom providers to integrate with document-management systems.

[Ken Sykora]

I think it works okay in that scenario, but in the scenario where you have thousands of media assets it starts to break down and that's where you need that next level of organization. I'm okay with the idea of media sets but can we allow maybe a tagging feature to them, or some other way to categorize within media sets?

--Sent from my phone. typos ate espected.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/deShLonzdhwJ.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Chad Rosenthal]

+1 everything Dan Diplo said.

[Ken Sykora]

Definitely a provider model. Having them in S3 would be a godsend.

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/elnXqOYz2n8J.

To post to this group, send email to umbra...@googlegroups.com.

To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

[Slawek Oss]

When you create a new document, document type list should be rendered as radio style list if number of elements is <= 3 (99% cases) and standard dropdown if >3.
Just less clicks for the user and better usability.

[Darren Ferguson]

Yup and over 85% of statistics are made up on the spot :)

I've never had 3 or less doctypes!

[Slawek Oss]

Do you have more than 3 doctypes under particular nodetype (besides home) ? 

[Darren Ferguson]

Sorry Slawek - I should have read a bit more thoroughly -  I didn't read the whole context!

Still prefer a dropdown though.

[Dan Diplo]

On Thursday, 28 June 2012 18:15:08 UTC+1, Slawek Oss wrote:

When you create a new document, document type list should be rendered as radio style list if number of elements is <= 3 (99% cases) and standard dropdown if >3.
Just less clicks for the user and better usability.

I'd agree with that. If there is only 1 DocType available is it even worth showing a radio-button/list given the user has no choice?

I'd also still like to push for the ability to select the default doctype to pre-select when there are more than one available. I think this is really important for usability. Also, to be able to limit what DocTypes can be created under the root Content node is also pretty essential.

[Thomas Kjær Nielsen]

+1 for the suggestions by Dan

/Thomas

[Slawek Oss]

With button list you further reduce number of clicks to just one and description could  change on hover action.
Of course default doc shuld remain intact and size of this list (ui change threshold) could be configured somewhere in config.
It raises inconsistencies in ui but may be worth, especially for end users with less umbraco "awarness".

[Tony Bolton]

I 'defected' from Sitefinity a couple of years back, but one of the things I did like about the UI was the drag and drop capability of 'parts' in the live editing.

One of the biggest criticisms I get from clients is why you can't just drag and drop components onto the page and in position.  I know this would be an awful lot of work to tack on to the UI as things stand, but it'd be a big win for general Umbraco users rather than developers.  Perhaps if macro's could be marked as widgets allowing them to be selected from a library panel within the canvas view or something?

[hor...@gmail.com]

1+ for the ability to select a default doctype, like it is possible to select a default template.

My editors (not using the CMS on daily basis) often create a new document with the wrong docType, when the correct docType isn't the default/first item of the drowdown.

It seems like the docType order of the dropdown is generated alphabetically, and therefor it can be solved by naming the other allowed child document types xNews, xContact etc. to make your wanted docType the first item in the dropdown... This 'hack' seems kinda silly :-)

I prefer the dropdown over the proposed button list.

[Shannon Deminick]

Couple of UI stuff that hasn't been mentioned on this list ( i think  :)

• I really dislike how everything is 'created' in v4 in dialogs. In v5 we did away with create dialogs and IMO it was a much nicer experience, it was much easier to develop and we had much more room on the screen where we could have even had some 'tips' or 'help' info
• Revamping the 'Create' button at the top of the screen so that it uses the newer create screens (not dialogs) and make it really useful so it is actually the go to place for creating all content.
  
• Having a JS panel that slides down (or similar) to display the top bar containing the About, Logout and Create buttons so that we move the actual content editing part of umbraco to the top.
• The JS require to resize all of the panels = this makes the UI slow. In v5 this was done with pure CSS ( http://issues.umbraco.org/issue/U4-98)
• Tree syncing and app deep linking that works 100% of the time  http://issues.umbraco.org/issue/U4-40) 
  
• Keyboard nav in tree (this is super easy to do but is even easier if we are using the newer JSTree lib as in the above issue)
• Contextual searches for any tree (http://issues.umbraco.org/issue/U4-8)

[Chris M]

My personal list in no particular order (warning - some may be good, others are probably very terrible ideas).  I apologize in advance for being so long/ranty/etc:

• The top bar (Create / search / about / help / logout) seem like it should exist outside of the currently selected section.  The behaviour of some of the pieces is a little strange / useless to me also:
• I never saw the point of the "Create..." button at the top of the screen - does anyone actually use it?  Sure it helps first time users who haven't discovered the context menu yet, but it's not consistently available (members, users).  I'd suggest either removing it or making it available on every section, and possibly making it have a dropdown associated that allows you to pick what "thing" you want to create (via something like Bootstrap's button dropdowns:  http://twitter.github.com/bootstrap/components.html#buttonDropdowns ).
• The search should either have its label text changed so that it's clear that it's for the current section (eg "Search content..." replacing "Type to search...") or be extended to search everything in the backoffice (and made available on all sections).
• About is imo too unimportant to get its own button on every screen.  I personally think that there's some room for a "Configuration" [or, if it didn't already exist, "Settings"] backoffice that displays some information about the data in the config files, and could potentially be used in the future to provide functionality to update or set these options (404 pages, use directory urls, stuff like that), but also the details on the installed version of Umbraco.
• The logout button could be overloaded to provide users with the ability to change their passwords, by changing "Logout: username" into a button dropdown for "username".  I know there's a Change Password dashboard page by default on Content, but I don't think that any user management stuff belongs there.
• Restriction of content types that can be placed immediately under the content node.
• If content doesn't have a template, don't provide a link to the document (it'll 404 all the time, won't it?).  I may be misusing Umbraco in having these content nodes that just provide data for rendering their parents or navmenus or whatnot, but if it's a common misuse, then I don't think that some sort of status overlay (like the "new" star on unpublished content would hurt).
• The rich content editor experience can be improved:
• The TinyMCE editor toolbar on content nodes should be moved to above the individual TinyMCE windows IMO.  The location next to the save / publish / preview buttons implies that it's something that will apply to everything within the content node.  Also, the hack to get it to that location means that people can't add extra actions to content screens without needing to write their own workarounds to move the TinyMCEMenuBar.
• Embedding macros into content areas is a weakness (my workflow on one of my sites is to add the macro, save, open the HTML, remove some cruft that gets added then save again) but I don't really know how to improve the situation with this one.
• Additional cross-platformability.  I remember for the longest time that Macros would crash Chrome.  Content editors at a company I work with recently got so frustrated that they upgraded TinyMCE to the latest version to try to fix issues with pasting from word in Webkit-based browsers on apple machines - these sounded like Umbraco-related issues [as they weren't fixed with the upgrade, though TinyMCE's test works for them] and they weren't able to fix them even with an upgrade.  100 non-closed issues on codeplex match for "tinymce" (~10% of all issues).  I guess my point is that the RTE is where much of the pain seems to be getting felt, so it probably justifies a bunch of focus to get right.
• The user management is a bit of a weakness for bringing Umbraco into certain places (like government) - being able to (by configuration) removing admins' ability to set passwords is a (relatively easy) win that is something that I've seen asked for a number of times.  This would also need to have either a forgot password process or a reset password process added.
  
• All items should have useful context menus:
• Section titles (eg Users) should IMO allow you to create the items underneath.  This does sort of factor into the comments I made earlier about removing/altering the "create" button.  Right clicking on the Users root node should allow you to create  a user, create a user type, create a user permission.
• Empty context menus should have an unselectable "(no actions)" or "(empty)" or something rather than displaying as ~5px high grey rectangles (eg members > members > a's context menu).
• I know it's a larger change, but I think that Create should be made more contextual.  "Create content", "Create user", "Create stylesheet" should be used instead of "Create".
• I'd love to see drag and drop and multiple uploads supported for media in the core.  I'd also love to see options around file path naming, to eg put files under a certain naming scheme, such as not including the node id (of course, you can do this with save event handlers, but it seems like something that is simpler to implement in the core than tack on as a File.Move).
• The members section needs a little TLC.  To illustrate how neglected it is, in 4.7.2, the Members > Search node ships with a 404'd image.
• The members node in the members section should be rejigged in some way.  At the very least, you should be able to create a member by right clicking on a letter and clicking "Create". 
  
• Empty nodes currently display no information that it's empty.  The Others section displays nothing if it's empty.
• The "Search" isn't really a node as much as an option.
• The Dashboard widget does a better job than the tree in general.  Either way, one should be picked, and used as the "right" way to find and deal with members, and this should be used for all listing and viewing of members.
• Right Click -> Open in new window / Ctrl-click / middle click and other similar gestures should work on the sections.  Rather than javascript:void(0), even having "#sectionname" as the section hrefs would improve the situation significantly.  One of those small hassles.
• Have the sections reload their trees when you navigate back to them / have the tree of the current section reload if you click on the section icon.  There are a few issues that I've seen around node names being wrong or not updated when you move away and then come back to a section (which are all fixed by reloading).
• Allow resize (and/or hiding) of the left tree area.  If I need to edit something quickly in the developer tab, having the maximum amount of screen space available is handy.  On the other hand, in the content tree it is often very handy to be able to see 6 levels deep easily, so a wide tree is useful.
• Also, very minor, but making certain items unselectable in browsers (via eg moz-user-select in mozilla) adds that tiny bit of extra polish (tab headings, section icons, button text, label names etc are all candidates for this) and saves a bit of frustration for users who fail at clicking.

In terms of bugs, I know that things don't work all that well when you resize; that the Umbraco packages repository in 4.7 is kinda broken (.js 404s on the subsection views; if you expand the subsections and then move to a different page then come back, they change to "Website utilitiesUmbraco PROStarter Kits..."); and that when you're logged out you get all sorts of funny behavior when trying to save things (eg cshtml gives you an error prompt simply stating "Error occured: false").  I haven't had the chance to check these out in the latest build yet though so I haven't reported issues yet.  It's on my (hueg) to-do list though...

--Chris

[Samuel Moore]

I love the media sets idea

[Shannon Deminick]

Hey @Chris! awesome feedback! :) Just added some comments to a few of yours below ( i didn't comment on them all, but pretty much agree with everything !):

• The top bar (Create / search / about / help / logout) seem like it should exist outside of the currently selected section.  The behaviour of some of the pieces is a little strange / useless to me also:
• I never saw the point of the "Create..." button at the top of the screen - does anyone actually use it?  Sure it helps first time users who haven't discovered the context menu yet, but it's not consistently available (members, users).  I'd suggest either removing it or making it available on every section, and possibly making it have a dropdown associated that allows you to pick what "thing" you want to create (via something like Bootstrap's button dropdowns:  http://twitter.github.com/bootstrap/components.html#buttonDropdowns ).

I think the 'Create' button thing needs an overhaul, not sure who actually uses it but I think it has potential to be very good if we pretty much re-created the integration. The whole 'create' system in v4 i think is extremely old and really weird. It uses an strange ui.xml file to do a bunch of stuff and its definitely not very clear. This is why i proposed changing the create dialogs to full create screens like we did in v5, it was WAY simpler. Essentially in v5 you could assign a JS method or a URL to a context menu. In the case of create, we just assigned the 'Create New' URL to the 'Create' context menu to load in the screen on the right.

 

• The search should either have its label text changed so that it's clear that it's for the current section (eg "Search content..." replacing "Type to search...") or be extended to search everything in the backoffice (and made available on all sections).

Yup, in v5 we had something called ISearchableTree, there's a task for this here: http://issues.umbraco.org/issue/U4-8 . Allows for all trees to be searched and is contextual to the current node/section you are in. Having the label change on the search box is such a simple but really awesome idea to make it ultra clear what you are searching.

• About is imo too unimportant to get its own button on every screen. 

 100% agree, its just hogging up very important space

• I personally think that there's some room for a "Configuration" [or, if it didn't already exist, "Settings"] backoffice that displays some information about the data in the config files, and could potentially be used in the future to provide functionality to update or set these options (404 pages, use directory urls, stuff like that), but also the details on the installed version of Umbraco.

We didn't finish this in v5 but definitely think we should have this in v4 was the idea of a 'System' application which showed you a ton of things about the system, helping for diag stuff, etc... we could add a ton of really useful stuff here. This could include the 'cache browser' since that is more of a diagnoses tool then belonging in the dev section (if anyone actually uses it, I'm not sure)

• The logout button could be overloaded to provide users with the ability to change their passwords, by changing "Logout: username" into a button dropdown for "username".  I know there's a Change Password dashboard page by default on Content, but I don't think that any user management stuff belongs there.

100% agree as well, this would be really useful 

• Restriction of content types that can be placed immediately under the content node.

Yup, we had this in v5 and a task is created for it here: http://issues.umbraco.org/issue/U4-3 but the name 'inheritable only' needs to be changed to something that makes more sense. 

• If content doesn't have a template, don't provide a link to the document (it'll 404 all the time, won't it?).  I may be misusing Umbraco in having these content nodes that just provide data for rendering their parents or navmenus or whatnot, but if it's a common misuse, then I don't think that some sort of status overlay (like the "new" star on unpublished content would hurt).

I also agree to show a 404 if no template is assigned, but I'm not sure if this confuses people if a 404 is shown when there is actually a page there. In v5 we displayed a embedded 'no template' template to make it clear to people but I'm not sure if this is the correct approach either. 

• The rich content editor experience can be improved:
• The TinyMCE editor toolbar on content nodes should be moved to above the individual TinyMCE windows IMO.  The location next to the save / publish / preview buttons implies that it's something that will apply to everything within the content node.  Also, the hack to get it to that location means that people can't add extra actions to content screens without needing to write their own workarounds to move the TinyMCEMenuBar.

In v5 the toolbar buttons were contextual to the current editor you are working on and it was actually pretty easy to move the TinyMCE buttons into that spot without hacking TinyMCE. So if you clicked on a standard text box and it didn't have buttons assigned to it, then no buttons would display, but if you clicked on a TinyMCE editor, then buttons would appear. We also had an API to support other PropertyEditors to add their own custom buttons quite easily. We have a task to port these concepts over to v4: http://issues.umbraco.org/issue/U4-34

• Embedding macros into content areas is a weakness (my workflow on one of my sites is to add the macro, save, open the HTML, remove some cruft that gets added then save again) but I don't really know how to improve the situation with this one.

• Additional cross-platformability.  I remember for the longest time that Macros would crash Chrome.  Content editors at a company I work with recently got so frustrated that they upgraded TinyMCE to the latest version to try to fix issues with pasting from word in Webkit-based browsers on apple machines - these sounded like Umbraco-related issues [as they weren't fixed with the upgrade, though TinyMCE's test works for them] and they weren't able to fix them even with an upgrade.  100 non-closed issues on codeplex match for "tinymce" (~10% of all issues).  I guess my point is that the RTE is where much of the pain seems to be getting felt, so it probably justifies a bunch of focus to get right.

We just need to overhaul/rewrite how it is done and borrow the code from v5. in v5 we didn't touch any of the TinyMCE souce, we just created plugins for it and everything including the inline macros worked really well with nice Ajax support. There's a task for this too: http://issues.umbraco.org/issue/U4-20

• The user management is a bit of a weakness for bringing Umbraco into certain places (like government) - being able to (by configuration) removing admins' ability to set passwords is a (relatively easy) win that is something that I've seen asked for a number of times.  This would also need to have either a forgot password process or a reset password process added.
  

100% agree, we should have this functionality on the login screen 

• Right Click -> Open in new window / Ctrl-click / middle click and other similar gestures should work on the sections.  Rather than javascript:void(0), even having "#sectionname" as the section hrefs would improve the situation significantly.  One of those small hassles.

I think you can ctrl+click on the apps in v4 to launch a new window, if it doesn't then it should ! :) I think this functionality was removed by accident at one point but was brought back in a later release... though I'm not 100% sure

• Have the sections reload their trees when you navigate back to them / have the tree of the current section reload if you click on the section icon.  There are a few issues that I've seen around node names being wrong or not updated when you move away and then come back to a section (which are all fixed by reloading).

Yup, the tree essentially needs another rewrite but again we should be able to borrow all of this from v5 as tree syncing, etc.. was significantly improved there (http://issues.umbraco.org/issue/U4-40) 

• Allow resize (and/or hiding) of the left tree area.  If I need to edit something quickly in the developer tab, having the maximum amount of screen space available is handy.  On the other hand, in the content tree it is often very handy to be able to see 6 levels deep easily, so a wide tree is useful.

I think you can do this already in v4, its just not very obvious. There's a super small 'handle' on the left pane border to hide the tree, though i don't think it resizes.

[Michiel van Oosterhout]

On Sun, Jul 1, 2012 at 12:31 AM, Chris M <ma...@christophermaish.com> wrote:

My personal list in no particular order (warning - some may be good, others are probably very terrible ideas).  I apologize in advance for being so long/ranty/etc:

I think it's all great feedback, because good UX is a million little things coming together. 

[dwhite]

On the topic of nodes w/o a template:

In my mind, one of the big weaknesses Umbraco has is the inability to have modules,widgets, or just straight data-nodes. I think that's why people have gotten into the habit of using content nodes without a template to have ability to do some of these things. 

I'd really like to see:

- The ability to have modules/widgets. Which would basically be content nodes that do not have a URI and are only used to be referenced in other content nodes and embedded into templates. Their markup/template would be embedded in when they're referenced.

- Pure data-nodes. Kinda like the modules, except they never have a template. They're just used to supply data. For example, say you want to manage all your staff profiles in one location. However, their data needs to be displayed on their department staff page, the main contact page, and other staff listings. Instead of having their data exist all over the site, it'd be nice to be able to reference the data from a data-node source. 

Anyway, it's a rough idea. I wouldn't know how to go about it. It's just something that really does cause troubles & hacks though.

[j.br...@digibiz.com]

Have a look at this forum topic for something similar: http://our.umbraco.org/forum/developers/api-questions/9478-Write-node-to-umbracoconfig-xml-without-publish.

[Randy McCluer]

+1. I think Kentico has a DataTables concept that looks interesting.

For widgets, I think it usually makes sense to have the template/markup associated with the widget. In v5 we built our own widget management package, where each WidgetArea was defined in the content tree with its widgets as its child nodes. Then we just used used something like RenderPartial to render them inline in the appropriate spots. Ended up pretty similar to how Wordpress sidebars & widgets work.

[Dan Diplo]

On Monday, 2 July 2012 16:53:40 UTC+1, dwhite wrote:

In my mind, one of the big weaknesses Umbraco has is the inability to have modules,widgets, or just straight data-nodes. I think that's why people have gotten into the habit of using content nodes without a template to have ability to do some of these things. 

I'm not sure I agree. I actually think the strength of Umbraco is the flexibility and unanimity the current structure gives you. All the things you mentioned you can currently do with Umbraco, and many more too. The simplicity of the current structure makes it really easy. All the CMS's I've seen that have dedicated data tables etc. tend to have confusing and complicated UIs.

The ability to have modules/widgets. Which would basically be content nodes that do not have a URI and are only used to be referenced in other content nodes and embedded into templates. Their markup/template would be embedded in when they're referenced. 

You can create a section outside of your Home page (ie. parallel to content) and then use uComponents multi-node picker to create a widget picker to select the widgets you want to pull into another node. You can then render them wherever you want.

- Pure data-nodes. Kinda like the modules, except they never have a template. They're just used to supply data. For example, say you want to manage all your staff profiles in one location. However, their data needs to be displayed on their department staff page, the main contact page, and other staff listings. Instead of having their data exist all over the site, it'd be nice to be able to reference the data from a data-node source.  

If you have a node without a template then it will always 404 when you visit it's URI, effectively making it a data node. To do what you suggest you create a Doc Type call Staff Member, give it no template and nest all the nodes somewhere outside your home page. Then you can easily pull all the nodes in using either XPath or Razor. Very simple and something that I've done loads of times in Umbraco. 

I do agree it doesn't make much sense for nodes without a template to have a URI, but then again it doesn't really do any harm if they 404 which effectively means they don't exist.

I don't see any reason to make Umbraco more complex by having all different types of Doc Types when the current system lets you achieve pretty much anything when you know how.

[dwhite]

@Dan

I completely agree with you about the Umbraco structure and how it is much better than most CMS (that are module focused). That was one of the first things that really got be hooked on Umbraco from the beginning. 

I was only saying that there are times when modules are very useful, if not necessary. And I wasn't aware of workarounds some of you folks are describing. I'll have to give 'em a try. :)

[Adam Shallcross]

+1 for everything Dan has just said...

We definately do not want to make Umbraco and more complicated than it has to be.

That is definately its strength in the marketplace against a number of other CMS's

Its simplicity for both devs and editors is what makes it great and we would all do well to remember this.

We do not want to replicate V5 in V4, as we are not solving anything, just shifting the problem around a bit.

That is all :)

Cheers

[Thomas Kjær Nielsen]

I do agree with Adam and Dan :-)

We do not need to make Umbraco more complex than it is.

Sometimes though - on large sites - it could make sense to move the "shared content" eg. the content you are going to pick with the MNTP to a "real" repository.

We always use another "rootnode" like Dan says. But sometimes this part of the tree gets so big and full of content that it is getting hard to get an overview - and it takes a lot of clicks to use the MNTP to find your content.

But the great thing about using the existing content tree, is that you get a lot of functions "for free". Like scheduled publishing and all of the existing XSLT functions.

I have sometimes thought about something like http://our.umbraco.org/projects/website-utilities/documents build into the core. It could be 100% a UX thing, so you could just define a "content-section" in a XML-file eg. "Section A", and on the properties tab on a node in the existing content tree you could select "use as root-node on 'content section A'" or something like that. Then the content would only show op in the content Section A (Was called App in v5), and you can easily split up large content trees. 

 

In other words - a more standardized way to do content repositories without loosing the functionality of the existing tree.

I know that it won't solve the many clicks to select shared content - but that could be solved with a search-function.

Just my 5 cents - don't know if it's a very specific use case :-)

/Thomas

[Michiel van Oosterhout]

Warning, rant ahead (nothing personal):

 

In my mind, one of the big weaknesses Umbraco has is the inability to have modules,widgets, or just straight data-nodes. I think that's why people have gotten into the habit of using content nodes without a template to have ability to do some of these things. 

I'm not sure I agree. I actually think the strength of Umbraco is the flexibility and unanimity the current structure gives you. All the things you mentioned you can currently do with Umbraco, and many more too. The simplicity of the current structure makes it really easy. All the CMS's I've seen that have dedicated data tables etc. tend to have confusing and complicated UIs.

The solution where nodes are used as widgets is neither simple nor intuitive. It's not a sign of Umbraco's strength, it's a workaround that is a sign of a particular area where Umbraco is really lacking.

If this is confusing and complicated in another CMS, doesn't mean it can only be that way. Let's take Sitefinity CMS for example: editors just drag and drop widgets onto widget regions on the page. Definitely way ahead of Umbraco. I don't see how you could look at that, compare the feature with Umbraco and say another CMS is confusing and Umbraco is simple... 

 

The ability to have modules/widgets. Which would basically be content nodes that do not have a URI and are only used to be referenced in other content nodes and embedded into templates. Their markup/template would be embedded in when they're referenced. 

You can create a section outside of your Home page (ie. parallel to content) and then use uComponents multi-node picker to create a widget picker to select the widgets you want to pull into another node. You can then render them wherever you want.

Please think about the end users here. What you describe is not simple. It requires users to jump around the CMS from section to section to combine content. 

Umbraco already requires editors to jump through hoops when editing, and the whole editing experience is highly decoupled from what they will ultimately see on the page. Your solution just adds more steps and more indirection. 

 

- Pure data-nodes. Kinda like the modules, except they never have a template. They're just used to supply data. For example, say you want to manage all your staff profiles in one location. However, their data needs to be displayed on their department staff page, the main contact page, and other staff listings. Instead of having their data exist all over the site, it'd be nice to be able to reference the data from a data-node source.  

If you have a node without a template then it will always 404 when you visit it's URI, effectively making it a data node.

Nope, it's still a content node without a template. A data node simply doesn't have an end point, and no 404 either. This is what I mean when I say we are limited to workarounds in Umbraco. 

I do agree it doesn't make much sense for nodes without a template to have a URI, but then again it doesn't really do any harm if they 404 which effectively means they don't exist.

Indeed it doesn't make sense, we just learned to live with it.

 

I don't see any reason to make Umbraco more complex by having all different types of Doc Types when the current system lets you achieve pretty much anything when you know how.

Yes, when you know how. Which is another way to say: when you understand how to work around the issue and abuse the content tree for everything.

Have a look at Composite C1 CMS. It has a concept of applications that you can add to a node. A weblog would be an example of an application. These application can define routes, effectively making their containing node a namespace. The tree does not contain e.g. nodes like /archives/2012/07 or /authors/michiel, but the application is still able to handle these routes. 

I assure you it's an elegant solution, and one that would greatly benefit Umbraco. Imagine how much cleaner a blog package would be for such applications! Especially if the application root is like an MVC area, with it's own controller(s) and views. Win!

[Michiel van Oosterhout]

The argument that we don't need to make Umbraco more complex than it is is strange to me. Who are we talking about when we make this argument: end users or developers? 

If we can't add new features to make it easier for editors because we are afraid developers will not understand, then I think we can close this topic, no?

[Niels Hartvig]

While I agree with you, Michiel, I'd like to ask you - and everyone else - to keep the tone friendly. 

Rants can go somewhere else, where less peoples time are wasted. It's a shame that some very good points you make can go unnoticed as trivial ranting. 

Best

Niels

On Tuesday den 3. July 2012 at 10.09, Michiel van Oosterhout wrote:

The argument that we don't need to make Umbraco more complex than it is is strange to me. Who are we talking about when we make this argument: end users or developers? 

If we can't add new features to make it easier for editors because we are afraid developers will not understand, then I think we can close this topic, no?

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

[Dan Diplo]

On Tuesday, 3 July 2012 09:05:40 UTC+1, Michiel van Oosterhout wrote:

The solution where nodes are used as widgets is neither simple nor intuitive. It's not a sign of Umbraco's strength, it's a workaround that is a sign of a particular area where Umbraco is really lacking.

That is your opinion, Michiel, and is perfectly valid as such, but don't mistake your opinion as an objective fact. I disagree. I think the fact that all content is part of the same tree is a massive plus for Umbraco. You get versioning, scheduling, sorting, event-handling, previews, inheritance and the ability to apply alternative templates to it with ease. You can access the raw data and easily transform it (to JSON, say). You can cache it. You can pull it in via AJAX requests (which is a good reason why "hidden" nodes still have a URL since you pass in an altTemplate and render them). It is extremely powerful and flexible and easy to work with. 

Trying to change Umbraco to be something it is not risks breaking the very thing that makes Umbraco so appealing. Be careful what you wish for...

Please think about the end users here. What you describe is not simple. It requires users to jump around the CMS from section to section to combine content. 

Umbraco already requires editors to jump through hoops when editing, and the whole editing experience is highly decoupled from what they will ultimately see on the page. Your solution just adds more steps and more indirection. 

Again, I disagree. Having all Content in one tree means editors know exactly where to look. I've personally trained many clients in using Umbraco sites I've helped develop and they've all agreed it is simpler to use than other CMS's they have used. This goes from large, international organisations with many users to small sites with one editor. I can tell you for a fact that from my experience, and people I've spoken to, content editors love Umbraco.

Take the widgets example. Here's how it can easily be done in Umbraco. You have  a tree of widgets under the Content node like this (I've blurred text to protect data):

And then you create a tab called Widgets and use multi-tree node selector to allow them to select widgets:

Very simple, but very powerful. And you can create and render your widgets using whatever you like - Razor, XSLT or even as User Controls. And unlike other CMS's you can create widgets that are not tied down to using WebParts, ASP.NET controls or other awful web-forms technology that is clunky and out-dated.

And I've used SiteFinity and the consensus where I work is that it is far less user-friendly than Umbraco. And don't even mention Kentico or other "modules" based CMSs.

Do not mistake not having a fixed way of doing things as a weakness of Umbraco; it is its strength. Umbraco allows you to solve a problem in many creative ways. It's power is being a simple and unified framework with endless possibilities. That's not to say it is perfect - we know that - but I'd rather improve it in ways keeping with the original philosophy rather than try and turn it into just another CMS.

[mattbrailsford]

I think this could go either way to be honest. If we want to keep it simple, we could add the ability for content to be stored in multiple content trees, then it's just a case of defining those tree (I'm thinking probably via a config file, but this might conflict with the argument that it's not very user friendly). On top of this, we could then add a flag to Doc Types to say whether the template is routable. If it's not, it doesn't bother showing all the URL based stuff (preventing it from ever being navigated to). If you wanna go all out, then creating a section + new tree + new "Types" editor tree is also entirely possible.

Would the simpler option solve any of the issues raised? or would you still see it as a "workaround"?

[Niels Hartvig]

There's nothing that prevents us from providing a *default* way of doing widgets using features already in place but with an enhanced UI experience. 

Research from Mark Boulton Design revealed that the lack of a decent UI for managing widget-like content was one of the achilles heels of the back office for editors. Both MBD and us believes that this can be done with the existing APIs / data structures in Umbraco as it's mostly UX sugar on top of what's already there.

This won't turn Umbraco into a module or widget based CMS, but solely make it easier and more straightforward to support widgets and give end users (editors) a better and richer experience. All *without* compromising the flexibility that makes Umbraco attractive to those who consider that (flexibility and full control) a key feature.

/n

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/iAW0EyKVJ_sJ.

To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

--

- 

Kind regards,
Niels Hartvig

Chief Unicorn (founder)
Umbraco - the Friendly CMS

Lindholm Havnevej 31
DK-5800 Nyborg
Denmark

http://umbraco.org
Phone: +45 70 26 11 62

[Richard Terris]

Has there ever been any sort of surveys carried out with Umbraco?

I'd be willing to bet that the number of dev users far outweighs the number of content editors.

I think if there are issues with content editors perhaps we could figure out if there are any issues that affect them all? Otherwise I'd say it's either how the app has been built or how good the training is.

I'd say Umbraco is mainly a developer's CMS, but surely it's the responsibility of the dev team to build correctly with planning in advance.

I have seen too many sites where the developer has a root document type and every other document type inheriting from it, meaning properties are on every page where not needed on 1/2 of them.

I don't think Umbraco is limited any more or less than the developer - let's be honest, out of the box Umbraco doesn't really "do" anything

[Niels Hartvig]

We (Mark Boulton Design) did a big survey last year with 943 respondents but mostly developers ( 67% ) due to the nature of the target groups of our communication channels.

I've attached the results.

/n

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/sQkO0AHAV4oJ.

To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

[Adam Shallcross]

Again totally agree 100% with Dan and all his points...

That is exactly how we use Umbraco and it works a treat for pretty much any situation and any requirement.

Every company we work with finds Umbraco really easy to use and has never had a problem with this setup.

Also combined with the Macro container to control panels on pages and allow the editor the ability to control the content by answering a series of very simple questions, to control some quite complex queries, to access data from other systems allows you to pretty much anything you want to.

The macro container itself could do with some TLC and maybe a drag and drop interface would help, but be careful with WYSIWYG interfaces and canvas style pages as they are usually cumbersome and rely on everyone having the latest browsers.

We work with a number of large financial institutions and you are lucky if they have upgraded to IE7 yet, ley alone Chrome, Firefox or IE9.

The power of Umbraco is its simplicity and we need to be aware of this at all times in whatever direction it is taken...

Cheers

On Tuesday, July 3, 2012 1:23:21 PM UTC+1, Dan Diplo wrote:

[Richard Terris]

this pretty much backs up what I said, although I appreciate the target audience factor.

So again, on the whole I don't accept Umbraco being hard to use for editors - if it is the blame must lie with the developer/designer

/n

To unsubscribe from this group, send email to umbraco-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/umbraco-dev?hl=en.

[Dan Diplo]

On Tuesday, 3 July 2012 14:06:54 UTC+1, Niels Hartvig wrote:

Research from Mark Boulton Design revealed that the lack of a decent UI for managing widget-like content was one of the achilles heels of the back office for editors. Both MBD and us believes that this can be done with the existing APIs / data structures in Umbraco as it's mostly UX sugar on top of what's already there.

 

I'm not sure my experience with editors backs this up. Never-the-less I'd be interested to hear what your solution would be? Care to share, Niels?

I think multiple trees like Matt suggested could work, though I'm not entirely convinced it is necessary. The danger here is that Umbraco is so flexible that people use and develop it in may different ways. Trying to fix a "problem" that exists for one group of people might just introduce a whole new set of problems for another group. As Adam mentioned, a lot of the usability "problems" with Umbraco can often be down to the way a particular developer implemented a feature. You can argue that forcing people down a particular route will make Umbraco more coherent and easier for new developers, but at what price? If you have a Golden Goose you better take care of it :)

[mattbrailsford]

Lets be careful here, just because you are fortunate enough to have clients who understand the concepts and learn it fast, doesn't make anybody else's claims that it's difficult to learn untrue. Our aim should be to find out what makes it difficult for those users and try and improve it, whilst keeping existing users happy too.

I 100% agree with Adam in regards to the Macro container needing some TLC though. I've never been able to get that thing working :)

Lets keep things productive.

[Dan Diplo]

On Tuesday, 3 July 2012 14:48:11 UTC+1, mattbrailsford wrote:

Lets be careful here, just because you are fortunate enough to have clients who understand the concepts and learn it fast, doesn't make anybody else's claims that it's difficult to learn untrue.

But that's exactly the point I was making, since the contrary must also be true. The point is that any one person's claims regarding usability are not necessarily true for everyone else. Michiel thinks Umbraco "requires editors to jump through hoops when editing". I have not seen this. Neither of us are wrong, but there are many reasons and factors why this could be.

Our aim should be to find out what makes it difficult for those users and try and improve it, whilst keeping existing users happy too.

Absolutely. But improving something whilst not changing it fundamentally isn't easy. I believe the fundamentals of Umbraco are sound and it's flexibility is what gives it appeal. If the plan is to suddenly have different sections for Modules or whatever then this strikes me as a conceptual shift in the use of Umbraco and it needs proper debate.

[Niels Hartvig]

Dan,

Let me make one thing totally clear: We don't change the fundamental
design goal around Umbraco which is its simplicity and flexibility.
Period. Whatever preferred way you have for doing widgets for your
clients/end-users will be possible in the future.

That said - for some - the combo of a widget-tree and MNTP seems like
a way to use building blocks to compensate for features that Umbraco
doesn't do good enough. And it works - at least years UK Festival I
saw Lee Kelleher do a nice demo of how he used that technique to do
widgets for end users (with a combo of tiny templates for the widget
notes which was combined runtime using a uComponents helper method).
But just because it works doesn't mean that it couldn't be done more
elegant and better out of the box (after all devs needs to know that
it is possible and also implement the functionality). For end-users,
they still look at MNTP as their way of doing widgets and they need to
save+preview to see what they're doing - and they need to move to a
different section to create a widget they're missing. For some -
that's not the holly grail of UX ;-)

Nothing - except a lot of work - prevents us for standing on the
shoulders of the most creative solutions and hacks from the community
and build richer data editors to give editors a better widget
experience. For instance one that still used a widget tree, but where
you actually saw a preview of the widget in a drag'n'drop container
rather than just a tree of names you can move up and down. And one
where you - if activated - could click a 'Create new Widget (<=
configurable title of course)' and without jumping out of context
could add a new one.

All this would use the exact same techniques as most people already
use today, but bring a massively improved experience to the editors.

/n

> --
> You received this message because you are subscribed to the Google Groups
> "Umbraco development" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/umbraco-dev/-/WqXFchrP7MgJ.

>
> To post to this group, send email to umbra...@googlegroups.com.
> To unsubscribe from this group, send email to

> umbraco-dev...@googlegroups.com.

[Michiel van Oosterhout]

While I agree with you, Michiel, I'd like to ask you - and everyone else - to keep the tone friendly. 

Rants can go somewhere else, where less peoples time are wasted. It's a shame that some very good points you make can go unnoticed as trivial ranting. 

 

Ok, it's just something I feel strongly about...

Sorry if I offended anyone.

[Michiel van Oosterhout]

I think the fact that all content is part of the same tree is a massive plus for Umbraco. You get versioning, scheduling, sorting, event-handling, previews, inheritance and the ability to apply alternative templates to it with ease. You can access the raw data and easily transform it (to JSON, say). You can cache it. You can pull it in via AJAX requests (which is a good reason why "hidden" nodes still have a URL since you pass in an altTemplate and render them). It is extremely powerful and flexible and easy to work with. 

Trying to change Umbraco to be something it is not risks breaking the very thing that makes Umbraco so appealing. Be careful what you wish for...

I think a solution should have all those features you mention (because they are awesome to have), just be easier to use/discover for editors. 

Especially more visual, and less hierarchical. Have widgets as nodes is far from a WYSIWYG experience. That is what I mean when I say editors have to jump through hoops: they need to form a very specific mental model of several sub trees and how they relate to the actual front-end rendering of the page. That is not intuitive for all editors. 

[Michiel van Oosterhout]

Research from Mark Boulton Design revealed that the lack of a decent UI for managing widget-like content was one of the achilles heels of the back office for editors. Both MBD and us believes that this can be done with the existing APIs / data structures in Umbraco as it's mostly UX sugar on top of what's already there.

While I have no research to back my claims up, this is exactly what I meant when I said working with the tree for everything is working around an area where Umbraco is lacking. 

In fact, we I briefly discussed this with you at DUUG back in April. 

[Chad Rosenthal]

Bugger, just posted a long entry and then I got logged out. Grr...

* love the idea of switching the logout button to a dropdown that allows you to update your password and profile. Although, I would like the ability to turn that off since there are times that I don't want the client to update a password. Don't like the current location since the content tab should only have things related to content. If we need to have a section that doesn't fit in the different trees then maybe it would be best to have a landing page section that the user is taken to when they log in. From there they could go to content/media/etc. (although this might be helpful, not a big fan of it and currently think ideas like making better use of the top bar are better than a landing page).

* In training clients, found that they didn't always understand the little symbols in the tree symbolizing the status of the content node (published, unpublished, published with edits). I know you can see this in properties (see next bullet point), but I'll ignore that for now. Would love to brainstorm if others find this also, but maybe a bar across the bottom of the node that is colored and explicitly states the status, last published, and by whom. Now it is easily to understand for the non-technical.

* Add the ability for user admin's to disable user accounts from being able to see the properties tab. Many non-technical people get really confused by this tab and ignore it anyways. About 99.9% of the time, I regular content editor doesn't need to see this tab and it's just scary. If we have the bar listed above, then we won't need this tab most of the time. Still needs to be there for admins.

* Love the idea of default doc types when you create new nodes. 

* Would love to see a default sort order when creating new nodes. I find that v4 normally just appends new nodes to the bottom of the current 'folder', while v5 tried to put them in alphabetical order. I really didn't like alphabetical order all of the time, but it was a great idea. Would be great to have a dropdown beneath the allowable children that allowed you to select how new nodes were sorted when added.

* I know that this is a package, but would be great to add some text to the top of each tab in a document type. Would definitely help leave helpful instructions for the client to remember as opposed to on individual data type. 

That's all I can remember from my original

On Monday, June 18, 2012 1:29:34 PM UTC-4, Morten Christensen wrote:

Hi all,

There has been a lot of discussion about features intended for developers, but not much about the end users who are probably the ones who use the backoffice the most. So I would like to kick start a discussion about what can be done to improve the UI, so that it is more enjoyable, easier to use or simply bug free from an end users perspective. A lot of you most have talked with clients who have voiced frustrations about certain areas of the backoffice - maybe the Content Tree is not updating probably or maybe the fact that you have to Create a Media item and name it before you actually upload an image is an annoyance.

Please be as concrete as possible ;)

Best regards,

Morten Christensen

[Jason Prothero]

FWIW, I love that Umbraco content isn't *just* pages, but rather can be considered data.  I agree that it is a strength and once you get it can be a very powerful tool to solve tricky problems.

That said, some of the ideas around making lookups, data related items, and widgets easier to understand and use both from an editors point of view and a new developers point of view sound good.  I think its worth exploring.  

Any chance that we could take a look at Users permissions while we're at it?  For example, a certain role is able to create a certain doc type and other roles aren't (but they could select them in a MNTP).  Or perhaps certain roles wouldn't be able to see a "data/widgets" tree but can see them in the MNTP and select them on other content.  Does that make sense?

Thanks,

Jason

[Matthias Daun]

Are there still plans for a complete revision of the backend UI? Could not find anything about that in the new roadmap. Or will there be a focus on (functional) usability improvements for certain "modules"?

Thanks
Matthias

[Niels Hartvig]

The first thing we needed to have in mind when creating a roadmap (that we could commit to) was adding things we knew could make it. So if you look at the things planned, it's mostly easy wins for a start, followed by the preparation (and execution) of a new API.

In parallel with this there *are* plans of making UX sprints, but due to the Higgs Boson discovery, the fine folks of Mark Boulton (who's working on the new website of CERN) had postpone their work on an idea for a UX bootcamp. It'll come later this summer. As such we couldn't put it in the roadmap as we really didn't knew the complete scope (which we couldn't either even if it was submitted).

Alsothe roadmap represents what we know we're able to do right now with the resources committed. It'll naturally change as the community participate. Think of it as a bare minimum of things to come.

Best,

Niels...

[Matthias Daun]

fully understandable! Don't get me wrong, the roadmap rocks, you are all doing a great job. Just wanted to have an update on this topic, too.
Thanks!

[Dan White]

+1 for CKEditor. TinyMCE can drive someone mad at times. Non-savvy users have a very tough time with things that should be simple.

[Robert J. Foster]

Yup, +1 for CKEditor from me too… and it’s in-place editor support looks great – perhaps can be used to enhance the Canvas experience…

 

Robert Foster

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.

To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/YH6yzZH_vs0J.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Niels Kühnel]

It looks great, but what has it that TinyMCE hasn't apart from a nicer skin?

[Dan White]

To me the editing with CKEditor has always been smoother than with TinyMCE.

Other options that may be worth looking into:

http://xing.github.com/wysihtml5/

http://imperavi.com/redactor/

[Niels Kühnel]

After you suggested it I checked it out. Thanks! and I completely agree :) v4 is awesome. Paste cleaning is brilliant and the js definition of styles for elements is flawless. However, doing all the plumbing to integrate it with Umbraco is a lot of work?

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/vGE1ju_fg2UJ.

[Dan White]

I'm sure it'd be an incredible amount of work to replace TinyMCE in Umbraco and something that is way above my head. I wonder if this would be something suited for the Belle project?  

Here's another interesting one - http://www.raptor-editor.com/

[Shannon Deminick]

To re-engineer all the wysiwyg plugins and ensure compatibility with packages, etc would take a substantial amount of time.
That said, in belle the tinymce tool bar is inline with the editor so there's no more toolbar hacks, so it would be very possible for someone to implement a new property editor that uses one of these editors. But would then need to invest a lot of effort in building the wysiwyg plugins that are currently in place in tiny mce.

Sent from my phone

[Philip Harvey]

For the amount of effort involved, that time might be better spend fixing the problems / improving tinymce instead, thus avoiding severe breaking changes

Sent from my iPad

--

[Niels Kühnel]

It would probably slate Belle for v9. After Belle 1 it might be something to pick up. Especially to support  frontend/canvas editing.
But at that time TinyMCE has probably catched up. Phillip has a sound point.

[Funka!]

On Thursday, January 17, 2013 12:04:19 PM UTC-8, Shannon Deminick wrote:

To re-engineer all the wysiwyg plugins and ensure compatibility with packages, etc would take a substantial amount of time. 

I'd be totally happy with keeping TinyMCE for whatever legacy things still needs it, so that existing "packages, etc" would not need any time for retrofitting, but yet be able to choose CKEditor for any new primary "body text" properties if I should so like. (And for people who still love TinyMCE, they can totally keep.)

We constantly run into formatting glitches with TinyMCE and lack of abilities that CKEditor has never had trouble with. (For example, how to make nested bulleted lists? TinyMCE does this wrong, assuming it lets you at all. Want to insert a simple blockquote? Good luck figuring that out, you're stuck with 30px of left-padding instead! Inserting a photo and don't want the width and height attributes in there since it messes up your responsive design? Hmmm. Ever wanted to add a className to an element? Let me know if you find out how! Please also let's not talk about support for tables beyond the basics, disprespect for non-breaking spaces and special characters, and ...... I digress.)

Anyway, without me actually tackling this I know I'm not entirely confident about everything that's involved, but here seem to be the key features one would need for implementing CKEditor as a new data type:

• Insert/edit image dialog should be able to spawn a Media Picker
• Insert/edit link dialog should be able to spawn a Content Picker
  
• Allow certain buttons on editor to be turned on and off, like you can with TinyMCE. But since this would be a new data type, could totally re-imagine how this works. Customizing toolbars in CKEditor is pretty straightfoward when you look at the resultant JS config.
  

I understand that once a document is saved, certain replacements occur server-side, such as the {LocalLink} magic etc., so this wouldn't need to change, would it? Anyway, I'm just dumping brain contents here since I was thinking about it, maybe trigger any further discussion about any other gotchas/caveats I missed in my simple analysis above.

Thank you for your time reading all this!