Management screen in 2.3.0

Quote from: BobRay at Nov 14, 2013, 10:41 PM

Very cool.

Shouldn't the Element tree label be "Elements" rather than "Templates"?

It seems odd to be using what is usually a settings icon for plugins, though I'm not sure what would be better, maybe a hook since that's what they really are.

Is "Page Extras" the TV tab? Is there some reason for not calling it "TVs" ?

Thanks for the feedback, Bob!

While most devs will understand what is in each tab, most users stare blankly and click aimlessly or I just tell them to avoid the tab for that. I figured calling some things by different names might make more sense to end users. TVs means nothing to your average Manager user, they just need to know where to find how to put that image in - calling page extras might not be the best name granted but it's more obvious a name that Template Variables.

I moved the files tab closer to the content (resources) tab as they are most used by average users. I'm considering other ideas for the 'elements' tab, because it almost has a decent argument that it should be kept away from average users. Maybe a default user group of 'Admin but not Super Admin' who can do everything but can't see the 'elements' tab would be a better method? Obviously that can all be done with tweaking settings now, but would be good to have an out-of-the-box-hide-things-for-people-who-don't-build-sites user group

For the icons, although Font Awesome is, well, awesome - it doesn't have all the icons that make sense. I'm thinking of compiling a list of missing icons and use cases, etc and submit as issues on the repo. I know some of the icons I've chosen aren't ideal I just wanted to see how the layout/design felt where they were used consistently. I think for the most part they work well, but agree some could be more obvious what they are! It might be good to get feedback from MODXers about what they think icons for things like the 'plugins' section should be, and see if there are alternative icons in the set that can be used/which need to be requested very politely

Quote from: sottwell at Nov 14, 2013, 11:07 AM

Amazing!

Thank you

Quote from: sparkyhd at Nov 15, 2013, 02:07 AM

This looks really great. I hope there's a means by which we can get this implemented.

Also impressed by your French translations. Just say it in English, with a bit of David Ginola accent, shout a bit louder and generally they get the message

My French translations are second to none... I'm speaking perfectly fluent French RIGHT NOW! Can you hear me??

IMO, the Elements tab should be called Elements. It's easy enough to hide from naive users with the element_tree permission.

There are challenges to naming, in any case. There are pros and cons for making the terminology more approachable for non-developers. This is something to strive for in every case, however, at some point we need to give certain things a unique name and users will have to learn it. One could argue Template Variables is pedantic, I think it is and therefore would propose a name like Additional Fields for users, however, I generally do that with changes to the lexicon for my users. On Elements, I think that should remain elements, all the pieces that make up the site aside from resources. There is also the consideration that one day there would only be Elements, of which Resources would be a type.

The other consideration is i18n and that the words we choose to describe things might not translate well, unique words actually have advantages in this case as they may not need to be translated or fully translated and become a universal term.

I

I personally think that the naming is fine, however it would be useful if everything was editable via the lexicons ( or a language file ) so that it can be tailored for every client. Not sure if it is now as I've never looked into it but that could / would solve the problem for everyone ;o) [ed. note: paulp last edited this post 12 years, 11 months ago.]

Quote from: paulp at Nov 16, 2013, 08:38 AM

I personally think that the naming is fine, however it would be useful if everything was editable via the lexicons ( or a language file ) so that it can be tailored for every client. Not sure if it is now as I've never looked into it but that could / would solve the problem for everyone ;o)

Paul, everything is editable by either lexicons or via Form Customization. I've done precisely this in demo builds where the end users see the TVs Tab for a Resource as labeled Additional Fields.

I think manager customization is a bit of a hidden art that many don't budget into their project builds. This can be especially important for larger organizations with high turnover of staff. Smaller clients can either call you up to ask for assistance or just get you to do it (revenues )

Paul, everything is editable by either lexicons or via Form Customization. I've done precisely this in demo builds where the end users see the TVs Tab for a Resource as labeled Additional Fields.

That's the point, it's in 2 places, would be far simpler if it was all held in 1 place and we could simply download a file ( This would mean that file can be reused on multiple domains ) , do a search and update it which would reflect across all instances of that word / phrase.

Interspire used to provide this for their online shopping cart, and whenever I installed one I simply uploaded a saved language file which saved me a lot of time on every install.

The benefits are that we can spend a couple or hours creating a few standard ones ( depending on the clients we have ) and then reuse them for multiple clients.

Don't get me wrong, I love MODX which is why I've used it for years and fight with my company directors to continue to use it and I'll probably never move away from it, but I do feel that would be a nice feature ;o)

There is a very specific reason it can be changed in two places. The lexicon is for global changes to text in the install, so in theory it could be changed only there.

Form Customization would be used in the case of conditional changes to text. So if you wanted to use a term for a field that falls under a single parent. Or you wanted to only display a term to one user group member.

Being able to export lexicons or sets of FC rules (though FC needs to change in the future) would be awesome.

@pdincubus:
The responsive manager mock-ups look awesome! I realize this might seem anti-climatic after getting positive feedback from Bob and Susan, but I thought I'd just say it all the same.

@everyone:
One thing I've always thought of is to have a separate clear cache button. The rationale is that in my normal development cycle, I'm using a bunch of static elements and resources, and my real work is in the code editor, then uploading to the server, and then going into the manager and clicking "Clear Cache".

If nothing were done about this, my complaints would win a "First World Problems" award (i.e. it wouldn't really be an issue), but I'm wondering if anyone else shares the same thoughts.

Regards,
Tom