We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • JP,

    I'm implying that this contest is more focused on alternative themes than the default one. Not saying that it's bad, just that I think it could be better and have a potentially bigger impact on the default theme by dropping the requirement to deliver complete themes.

    I myself will not be entering anything into the contest, given that I can't design and I find choosing a pair of matching socks each day a challenge, but I am getting up to speed (albeit slowly) in Git and GitHub.
    I can never find matching socks either! tongue

    Whatever way this contest flows I will try to help out with the implementation part where I can, you don't want me in charge of pixels.
      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
      • 38290
      • 712 Posts
      I don't know of any tutorials on theming the Manager, but maybe some are out there. I'd start by looking in the manager/templates directory. You'll find the default theme there, which of course you could duplicate and start hacking away. There are several .tpl files which generate the markup for the Manager pages. In the CSS directory there are two files that make up the manager styles, index.css and login.css.

      MODExt is the JavaScript for the manager that extends ExtJS and is not theme specific. This means that unless you really are looking to get your hands dirty, you probably want to live within assumptions made by MODExt and focus mostly on the .tpl and .css.

      As far as the _build stuff, those are just optional tools we use to do things like compile Sass, fetch dependencies, and prepare files for production.

      yomonger is a command line tool (yeoman generator) that asks you a few questions about how you'd like to bootstrap your Manager theme and gets you headed in the right direction. Screencast here:
      http://devries.jp/blog/2013/11/22/meet-yomonger/
        jpdevries
        • 38290
        • 712 Posts
        Mark,

        I think I understand what you are implying. That this contest is a waste of time and should have been done differently and isn't about the default theme. What I don't understand is why you see it that way.

        The first sentence of the thread is:
        We seriously want to nail an incredibly usable and clean default theme for 2.3 themes for 2.3

        This whole thread started because of the default theme, and I simply made the edit to clarify that we aren't going to guarantee that the winner of this contest, whatever it be, is automatically the default theme. What if none of the submissions even work?

        Now, maybe I caused confusion by making that clarification and emphasizing the importance of non-default themes as options, but I'd be disappointed to see you succeed in steering the direction of this thread away from how it started, our desire to see the default theme evolve.
          jpdevries
          • 10378
          • 375 Posts
          Quote from: shorewalker at Feb 05, 2014, 01:01 PM
          <lame>I'm late to this thread and have done limited UI work, but I did once build a CMS for posting my own content and it was an instructive exercise.</lame> A few thoughts on how to succeed in Web CMS UI, biased towards helping non-technical users:

          • Step One: Find out why people like using WordPress. 'Cause many do. (I am not actually one.)
          • Step Two: Check whether people like WordPress because it gives them a big simple editing window for the content - and for websites that get updated seriously by non-technical people, this matters. In general, find a way to save all the wasted space in the first 612* - count 'em, 612* - vertical pixels before you hit the MODX content editing field in a normal resource editing window. Christian Bartels' work goes in this direction. The Edenweb work is pretty but makes this problem much worse.
          • Step Three: Think about whether we can get metadata off to the right, like Articles already does. You love metadata, and so do I. But when you're entering content, you are probably putting exactly the same thing into the Long Title and Short Title fields, and after a while this is going to p**s you off. Make one of the Titles a clone of the other by default, and put its field off to the right-hand side. (Note that in Articles, Long Title disappears by default.) Put the summary field off to the side too. And description. And the user info. And the MODX version details. And the name of the site, which for most end-users is never in question. (Let power users colour-code their sites, maybe.) And the MODX logo can be moved too.
          • Step Four: More broadly, think about whether there's some way to deal with the fact that content is best entered into screen areas no more than 100 characters wide, but everyone's screens now have a 16:9 aspect. (Would two right-hand vertical panels be doable?)
          • Step Five: Don't lose what's good, and there's a lot of that. The tabs (Documents, Settings ... ) and the Resources/Elements/Files tree are great solutions, even if the implementation of the trees has problems right now. The menu bar with drop-downs is fine in concept, though it could lose some vertical pixels.

          You are telling exactly what I'm thinking since I started using MODX.
          A content management system should focus on content an not on meta data.
            Freelancer @bitego http://www.bitego.com
            ---
            GoodNews - one of the most advanced and integrated Group Mailer premium add-ons for MODX Revolution!
            More infos here: http://www.bitego.com/extras/goodnews/
            • 18608
            • 112 Posts
            Every time I work with the manager I think it needs focus. IMO the UI right now is too much "everything at once" and I think a good goal will be to get better at serving the right elements on the right time.

            I have an idea for a concept where you send the tree out in an off-canvas menu and dedicate the manager to creating the content (or formatting it, I think most users create the content elsewhere and primarily use the content window for formatting). But, the thought of integrating this into ExtJs is a bit intimidating! Perhaps mostly because I haven't worked that much with it.
              Mathias Dannevang | Webdesigner at dannevang.org | Tweets @dannevang
              • 41825
              • 16 Posts
              Quote from: dinocorn at Feb 08, 2014, 02:23 PM
              I don't know of any tutorials on theming the Manager, but maybe some are out there. I'd start by looking in the manager/templates directory. (...) yomonger is a command line tool (yeoman generator) that asks you a few questions about how you'd like to bootstrap your Manager theme and gets you headed in the right direction. Screencast here:
              http://devries.jp/blog/2013/11/22/meet-yomonger/

              Thanks jp! I'll take a look around smiley
              • Quote from: dinocorn at Feb 08, 2014, 02:48 PM
                Mark,

                I think I understand what you are implying. That this contest is a waste of time and should have been done differently and isn't about the default theme. What I don't understand is why you see it that way.

                You're simply wrong there. I do NOT think this contest is a waste of time.

                If I thought it was a waste of time, I would not have offered modmore licenses, or spend the time trying to get my point across about a slightly different way the contest could be shaped in order to, in my belief, maximise the outcome.

                What I think is this and nothing more or less: designers trying to figure out ExtJS in order to submit working themes can be better spent by those people to create great mock-ups and iterate upon that, leaving the implementation to developers.

                In that sense, the part of the contest that needs people to build a full working theme that may or may not end up being used in the core or as package, yes I think that part of the contest and that part alone could be wasted time for the people building out entire themes. While it does get people to look at what's possible and how to do it, I, as developer that will gladly help doing the developing, would rather have designers focusing on what they do best: design. Most people are either really good at design or development, and not both like you JP. wink

                This whole thread started because of the default theme, and I simply made the edit to clarify that we aren't going to guarantee that the winner of this contest, whatever it be, is automatically the default theme. What if none of the submissions even work?
                Fair enough, the most important thing should indeed be that it is an improvement and works properly. That's exactly what I want too.

                Now, maybe I caused confusion by making that clarification and emphasising the importance of non-default themes as options, but I'd be disappointed to see you succeed in steering the direction of this thread away from how it started, our desire to see the default theme evolve.
                If you think I'm trying to steer this thread away from evolving the default theme, there is definitely a lot of miscommunication going on. All I want is for designers to focus on what they do best, so the end result is a default theme that is as best as it can be with the talent we have in the community.

                The primary reasons my interpretation of this contest is that it's focused on alternative manager interfaces instead of the default are:
                - themes need to be fully built out (if it's just about getting the right design, that shouldn't be asked from designers - a group of developers could build out the winner)
                - the edit in the first post that I interpreted differently than it was intended, which you just clarified.
                - indeed your clarifications about non-default themes, moving away from the one manager interface and shipping multiple themes with 2.3. Again, something you just clarified.

                Either way it isn't possible to release 2.3 right after a theme is chosen as it needs testing, so I don't see the problem in delaying a release an extra week for building the best theme.



                If we agree that we want the same thing, an improved design for 2.3, then we are somewhat on the same page and I propose we drop all misinterpretations and assumptions and just work on making 2.3 as great as it can be.

                If by now you still don't agree that it might be a bit unnecessary to build out a full theme in order for the team to review a submission and consider it for 2.3, then nothing I can say will sway your mind and you wont hear from me about that again. That doesn't mean I agree it's the best way to run this, but hey, this is a contest set out by MODX and if MODX wants to do it that way, then I'll just have to suck it up. I just thought the fact the first post wasn't finalised yet that the exact details were still open for discussion.
                  Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                  Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                  • 13460
                  • 47 Posts
                  As a UI designer I don't understand why you want to have a contest with visual, interaction, usabilty and front-end in 1 contest. I'm agreeing with MarkH: why not focus on mockups as final product. It sounds to me like a quick fix. It reminds me to a CTO saying "Why does it takes so long to handover these mockups?!" We gave you some bulletpoints you only have to design.
                    UI /UX designer + bit of Front-End Developer. Getting around with MODx Revolution
                    • 9995
                    • 1,613 Posts
                      Evolution user, I like the back-end speed and simplicity smiley
                      • 38290
                      • 712 Posts
                      It sounds like we have people wishing to submit just comps, as well as developers looking to help out. I hope people can team up to turn mockups into submissions.

                      This is a live thread and the final details haven't been announced, so they may change based on what we're hearing.

                      Our reason for not accepting just comps is as great as a comp can be it doesn't leave us with something that has necessarily gone through the "reality check" of theming in 2.x. Also, exciting as it may be for the winner to inspire or become the default theme for 2.3, it binds the release of 2.3 to yet another thing. If nothing else for the sake of time, we need to make sure that submissions are both feasible and clickable sooner than later.

                      Now this is not to say that a comp couldn't go through that process, based on developer feedback and tests, before ever being turned into code. It just isn't our intent to direct and critique each submission if it were a comp and decide what is and isn't feasible. We don't want to define that, because who knows maybe someone will surprise us on what is achievable with the tools we have to work with for backwards compatibility.

                      Maybe 3 weeks isn't enough time, that is up for discussion. We also aren't stopping people from forming teams and getting started now, on an existing comps in the wild.

                      Things I want to know:

                      • What is stopping people from having a go at existing comps in the wild?
                      • What sort of issues do coders have when theming the manager?
                        jpdevries