Revolution Manager User Experience and UI. Help make it amazing.

Quote from: david.brunelle at Aug 17, 2010, 04:35 PM

User Management
In Evolution, creating a "role" that was only able to edit resources was quite easy. You’d create a role, assign permissions (descriptions were all very straight forward written in plain English with little-to-no ambiguity). You’d then assign users to the appropriate role and you were done.
In Revolution, there are "User Groups", "Roles", and "Access Policies." When creating or editing an access policy, permissions are overly complex and cryptic. If I’m not a developer, for example, a permission with the name of "create" and description of "Basic "create" access on new objects" sounds like nonsense. If you want to add a new permission to an access policy, you need to know the permission name ahead of time. Without spending a significant amount of time reading documentation I was unable to set up a user that was only able to view and edit resources.

For what it’s worth, these are common Security terms for those familiar with enterprise security. Your end-users should never be going into the Security section, so I’d recommend hiding it from them.

People wanted more flexibility and granularity in Security from Evolution - there is no way to do that without introducing enterprise-level concepts. This isn’t a UI issue, per se, as much as an education issue. While yes, there can definitely be UI improvements, we will most definitely not be removing features because they are initially ’too complex’. I also envision custom security packages, or Extras that are Wizards to do this easier.

The Permission listing issue will be addressed in 2.1 or sooner, and is definitely a known issue.

Creating New Categories
In Evolution, you could create new categories on-the-fly when creating a template. You had the option to choose an "existing category", or specify a "new category." The option to create a "new category" at the time you’re adding an element seems to be missing.

Right-click on the Categories node in the Elements tree. You can create a root-level Category or a nested one, from any page.

Weblink vs. Symlink For an end user, I think the distinction between a Weblink and Symlink will be lost and will only create confusion.

For an end-user, the word MODx is going to create confusion. This isn’t a problem with revo - you just need to educate your end-user.

JavaScript Select Boxes I don’t see why every select box in the manager is actually handled with JavaScript/ ExtJS. It seems like a standard <select> element would offer better performance (eliminating the need for an ajax call) and accessibility.

I completely, 100% disagree. Doing the select boxes the way we do them allows for massive amounts of scalability - pagination of results, templated selects, dynamically adjusting selects, and instant field validation. A great example of this is the linklist in TinyMCE in Evo - it nearly crashes when you get to 1000+ page sites in Evo, due to the lack of pagination.

Settings Page
As others have mentioned, the settings page is not user friendly. Unless you know specifically what you’re looking for it’s much more difficult to find a setting, or understand what a specific setting does, when compared to Evolution.

You can easily click on a row to see a description of what it does, so the ’what a specific setting does’ complaint doesn’t make sense. And it’s *much* easier to find a setting, in my opinion, because you have all *kinds* of filtering options in Revo - search by key or name or description, filter by area, filter by namespace...

Also, it’s not entirely clear how one would edit a particular setting. Right-clicking or double clicking is not intuitive. Using an ajax call to save settings on blur seems to be inefficient and time consuming, especially if you need to edit multiple settings.

From the text right above the system settings grid: "Double-click on the value column for the setting you’d like to edit to dynamically edit via the grid, or right-click on a setting for more options. You can also click the "+" sign for a description of the setting."

As for the inefficiency, I disagree - ajax requests are much faster and easier to process than a full-blown page request.

If you’ve got suggestions for these criticisms, please do state them, we’d love to hear them - I know you have some good thoughts on this subject.

(Post edited to reflect areas where I’m misinterpreting you.)

Quote from: splittingred at Aug 17, 2010, 06:53 PM

For what it’s worth, these are common Security terms for those familiar with enterprise security. The idea of Access Controls is *very* familiar to people who do security daily. Your end-users should never be going into the Security section. I’d recommend hiding it from them.

I wasn’t referring to terms like "Roles", "Permissions", or "Access Policies" - I was referring to the names given to specific Roles or Permissions. I will say, however, that roles in Evo made much more sense: Administrator, Editor, & Publisher are pretty clear and descriptive. It would be interesting to see a listing of all permissions that would need to be assigned to an access policy in order to achieve identical (or equivalent) levels of access. In Revo there are two built in roles: Super User and Member. There’s a lot of ground to cover between those two ends of the spectrum. I’m curious why the built in roles were limited to these two?

Quote from: splittingred at Aug 17, 2010, 06:53 PM

While yes, there can definitely be UI improvements, we will most definitely not be removing features because they are initially ’too complex’.

I’ve used the acronym "UI" when I probably should have been using "UX" or "User Experience" - UX covers a lot more than how screens are organized. I think that you can achieve simplicity, while also providing access to granular controls. I’m a big fan of simplicity, and like Ryan’s mention of a "Dad Simple" manager interface.

Quote from: splittingred at Aug 17, 2010, 06:53 PM

The Permission listing issue will be addressed in 2.1 or sooner.

Awesome!

Quote from: splittingred at Aug 17, 2010, 06:53 PM

Right-click on the Categories node in the Elements tree. You can create a root-level Category or a nested one, from any page.

Thanks!

Quote from: splittingred at Aug 17, 2010, 06:53 PM

For an end-user, the word MODx is going to create confusion. This isn’t a problem with revo - you just need to educate your end-user.

Theoretically, I could train my users to write HTML and PHP. However, they want to know the bare minimum. They want as few options as possible, and clearly labeled text fields. Above and beyond that, I feel like you’re just asking for additional training and help desk requests.


Quote from: splittingred at Aug 17, 2010, 06:53 PM

I completely, 100% disagree. Doing the select boxes the way we do them allows for massive amounts of scalability - pagination of results, templated selects, dynamically adjusting selects, and instant field validation. A great example of this is the linklist in TinyMCE in Evo - it nearly crashes when you get to 1000+ page sites in Evo, due to the lack of pagination.

It sounds like there are valid technological reasons for the way select boxes are handled. My opinion, however, is that they detract from user experience (my experience, anyway.) I’m only offering feedback/ opinions. Not saying my opinions are "right."


Quote from: splittingred at Aug 17, 2010, 06:53 PM

You can easily click on a row to see a description of what it does, so the ’what a specific setting does’ complaint doesn’t make sense.

In Evo you can scroll down the page and read what each setting does. In Revo, if someone wanted to see what each setting did, that would be 100’s of clicks. Again - it’s my opinion this isn’t the best user experience.


Quote from: splittingred at Aug 17, 2010, 06:53 PM

As for the inefficiency, I disagree - ajax requests are much faster and easier to process than a full-blown page request.

True, if you’re changing one setting. If I were changing 5 settings at one time, for example, it would be: Change, wait... Change, wait... It feels like it would be much more efficient to make multiple setting changes if they were all submitted at once.


Quote from: splittingred at Aug 17, 2010, 06:53 PM

Really? We added drag/drop for sorting and tag insertion, quick update/create, one-click package management installs, MgrMgr *built into the core*, an easier to access Elements and Files tree, and you’re telling me Revo is *less* user friendly? I would seriously argue against this. Yes, there are bugs here and there (which any release of any product will have), and there are ways it can be improved. But saying it’s less user-friendly than a product that requires 4 clicks just to go edit a Snippet?

That’s what I’m saying - this is from my own experience, and feedback I’ve gotten from one of the designers I partner with. If you’ve done usability testing and research with designers, developers, and end users - then I might just be an edge case or impossible to please. If you’re basing this on your own experience or opinions, it might be worth getting feedback from users that haven’t used MODx before.

Quote from: splittingred at Aug 17, 2010, 06:53 PM

Unless we had at least $40,000 in donations, this isn’t really an option. (Plus I don’t think we want to create the idea of paying for MODx development.) Nor are we really wanting to completely rewrite the UX, but rather just improve it, as a complete rewrite would set us back a year again in development.

Fair enough.

Earlier, via Twitter, Jay had this to say:

It may also be that #evo is right for your project types. It’s not going anywhere anytime soon

He’s probably right. Also, I admit that I’m a bit of a freeloader... so I’m not sure I even have the "right" to be offering criticism. I just know that with Evo: It felt right. I was excited to show it to train my clients. With Revo, not so much. In all honesty, I might not be your intended audience.

Quote from: david.brunelle at Aug 17, 2010, 07:51 PM

I wasn’t referring to terms like "Roles", "Permissions", or "Access Policies" - I was referring to the names given to specific Roles or Permissions. I will say, however, that roles in Evo made much more sense: Administrator, Editor, & Publisher are pretty clear and descriptive. It would be interesting to see a listing of all permissions that would need to be assigned to an access policy in order to achieve identical (or equivalent) levels of access. In Revo there are two built in roles: Super User and Member. There’s a lot of ground to cover between those two ends of the spectrum. I’m curious why the built in roles were limited to these two?

Well, mostly because most people won’t really use Roles anymore, unless you’re crafting a pretty complex policy. Evo was primarily ’Role-driven’ for access - Revo shifts that more toward ’Policy Attributes’ (called Permissions, in an Access Policy). Roles are only used for the Minimum Role in an Access Policy, which allows you to restrict a Policy’s implementation to specific roles within a Group.

Re Settings auto-save: I’m not for preventing the autosave feature, but we could definitely improve it. What would be ideal would be the ability to set and ’tab’ through each setting as you save it, similar to Excel. This can be done in Ext, but the code needs some tweaking.

He’s probably right. Also, I admit that I’m a bit of a freeloader... so I’m not sure I even have the "right" to be offering criticism. I just know that with Evo: It felt right. I was excited to show it to train my clients. With Revo, not so much. In all honesty, I might not be your intended audience.

Everyone has a right to criticize, we just appreciate suggestions with the criticism. Your latest post has offered some suggestions that I think are helpful. The settings one, and Permissions list one were great. We’d love to hear more.

Quote from: TomMLS at Aug 17, 2010, 09:23 PM

1. Try to reduce how much/often the Manager reloads the entire page...becomes annoying.

Use Quick Update/Create.

2. Refactor all the Manager documentation for designers, not programmers. Programmers may be the ones who make MOXd go, but the bulk of users I would bet are designers, who need non-technical explanations which may need to be more verbose than those written for MODx programmers who have been using Revo since it was in alpha. Samples would also be good to have.

End-user documentation will be a target later; however, the main goal right now is to write developer and site builder documentation, since:

1. Developers often write the new Extras needed to get a new product started
2. End-user docs vary by client, and generic ’end-user documentation’ often doesn’t fit every scenario (especially in a product as flexible as MODx!)
3. Documentation will always lag behind code, especially so in Open Source. Remember folks, we released Revolution 2.0.0 under a month ago.

I’d love the ability to have TemplateVariable based TemplateVariables...

Like:

- TV: Need a sub navigation?
- other TemplateVariables

If yes:

- TV: Need a sub navigation? YES
- TV: start of sub navigation
- other TemplateVariables

if no:
- TV: Need a sub navigation? NO
- other TemplateVariables

If thinks that it is possible to mimic that feature with a Custom TV.

Could you point me in the right direction? It would really save 2 projects that I am working on...

I can’t give you any exemple since there are no example as of now.

But if you go to the documentation and try to setup a custom TV, and then experiment your own needed functionality, nothing block you to implement a behaviour similar to the one you depicted above.

I will not say that it will be easy (since you’ll ahve to build it from the ground), but it’s possible.

Now that i think about it, it could be a nice subject of tutorial.

Ok thx. I’ll see if I can do it...

Maybe it would be nice to create this function in the core? Or am I wrong with this?

FYI: I simply love MODx, ever since I started using it my work have been alot easier and my bos is very happy with the results!

The team will happily answer to you

I can see where it can be useful, but it can also be complicated since there are so many possible cases.
From my point of view, it’s quite specific and only custom TV can support your case, but i might be wrong.