Diagrams/Redesign [was Re: Lingo-ology]

Alright...here’s the first flowchart I created. This one is based on the current version (v0.9.0) just to give you an idea on how I’m doing this. It’s mainly just to give you a general idea on how the whole thing is structured. Based on the talk about redoing the manager, alot of this will probably change betwoeen the next 0.9 release and future releases based on a new manager layout. The reason is that with the new manager layout we have the opportunity to arrange things in a more logical fashion based on function, importance, and emphasis. Usability is the primary focus of the new manager layout. Looking at the flowchart, you can clearly see that there’s definitely room for improvement from a useability standpoint. Alot of functions could be bundled together and implemented in a much more useable fashion. But those are decisions that can wait when we really start digging into the new manager. However, keep in mind that some pre-planning will need to be made before we even touch on the design of the new manager.

For now though, we can use these as a tool to get an idea on how all the lingo and functionality of the Resources section flows with the rest of the manager. Plus, we can look at certain parts that will be pulled from the code and implemented as plugins and see how things will be impacted.

Take a look at the first flowchart and tell me where I can improve it to give a clearer idea on how the current version flows.

L8R!

And modelling myself after Jeff’s initiative, here’s an excel spreadsheet overview of pretty much everying in the assets and manager folders... should be a good basis for letting folks know how the system is laid out. Couple these two docs with a flowchart of how a doc is rendered and it’d be a killer developer documentation kit.

Adam, if you make more progress with getting Travis’s code up, please post it here.

Quote from: rthrash at Nov 12, 2005, 02:15 PM

Adam, if you make more progress with getting Travis’s code up, please post it here.

I’ve mad some progress, but it will definitely need some work.

The sessions have given me some problem. The sessions are now separated into separate frontend and manager sessions. Commenting out the session_name() function in assets/config.inc.php seemed to fix it temporarily.

You’ll also have to add an executable column to the site_snippets table. Originally I put this in as a tinyint(1) but I’m noticed later that there are three executable options (static, executable, and executable in the manager) so the column’s data type obviously needs to be changed, but I havn’t had time to see what to change it too. Once this is sorted out it will hopefully take care of the frontend, which was cought in a eternal loop whenever you try to use a snippet. Probably because it was evaluating it as static and found a refernce to itself in the comments.

There are also quite a few template issues, the menu doesn’t work at all in Firefox, and Ryan tells me it doesn’t work well in Safari either. I’ve had the best luck with Opera, strangely enough.

Right now I’m finally going to work on upgrading obledesign.com to MODx 0.9 (it’s been Eto+MODx for way too long!) but I should have some more time this weekend to look into Travis’ code. I’ll try to keep you all up to date with what I find.

Hmmm,

The code base provided my travis can be used to serve as a base for bluewater design but I’m thinking that it’s might be best recode the manager based on the things discuss so far.

I havn’t gotten really deep into Travis’ code yet. Mostly just looking at problem areas trying to get the thing to work. More than anythnig it seems to be a template redesign, and from what I’ve seen so far, I like what Raymond has suggested more than what Travis has done. So I don’t think that this should make us change much of what we already have planned.

The real question is which is the best starting point for where we want to end up: the current 0.9 code or Travis’ code? I really don’t have an opinion one way or another. I think Raymond will be the best one to make that call.

As Jason had suggested, we should do things gradually. Moving along with the project plan. We will first fix the major bugs and release 0.9.1. Next we can work on Merging resources, etc and so on.

I think the starting base should be 0.9.1 and then we gradually merge portions Travis’s code into the new system. The MTE will take some time as we are also working on the new parser.

I tend to think we start with what we’ve got, and incorporate any of Travis’s ideas that make sense.

One area we relly need to talk about is the way the tree is handled and how to perform bulk actions on pages that may or may not be in the same folder. That’s an area of usability that can be greatly increased and which I think I’ve got an idea for how to handle.

Here’s my stab at a menu reorganization. Some new stuff will need to be left out, but I think it’s more logical and blanaced (size wise):

Site
Home (Quick Links/Messages with common actions for newbies...)
Launch
Refresh

Content
Site Map -- bulk actions/overview (full width) menu tree
New Document
New Weblink
File Manager
Import HTML

Manage
Templates
{Flyout List to Edit}
TVs
{Flyout List to Edit}
Chunks
{Flyout List to Edit}
Snippets
{Flyout List to Edit}
Plugins
{Flyout List to Edit}
Manage
{Flyout List to Edit}
Intall Module

Tools
Install & Upgrade (to be done... reference SMF)
Backup Manager (can this copy all assets too?)
Remove Locks
Site Export (can this copy all assets too?)

Reports
Visitors Browsing
Site Stats (replace with slimstats?)
Site Schuedule
Audit Trail
Installer history (to be done based on Install & Upgrade system)
System Info

Admin
Manage users
Site Messages
URL handling
Content Defaults
Site Settings



Global links
help
my account
logout
search

Looks pretty good. Here are a couple of changes I’d like to see made.

Admin > Manage Users
No need to say we’re managing the users, it’s assumed. I say we go with a simple Admin > Users.

Admin > Site Settings
Again it’s assumed that we’re managing the site so we shouldn’t have to spell it out. I say Admin > Settings.

Manage > TVs
I don’t like Template Variables but I think it’s less confusing that TVs, so I say we use the full name until we change it. Manage > Template Variables.

Tools > Backup Manager
This seems deceptive, we’re not really managing backups we’re doing backups so I say we use Tools > Backup.

Content > Import HTML
Any reason to spell out HTML as opposed to just importing content? If it won’t do non-html like CSS, images, javascript then keep it as is, otherwise should be just Content > Import

Site > Launch
I’ve never liked the word Launch at all. To me when I’m a manager "launching" a site it means that I’m publishing everything and going live. I actually didn’t click this for a long time because I was afraid it was going to do something like that without asking me. Personally I think we can do without it and link the site title in the top right to the frontend. I also think that the MODx (version) could link to the manager homepage.

Reports > Site Stas
Again lose the Site, we know. I say Reports > Statistics

Reports > Site Schedule
Again lose the site. I’m thinking we should call it Reports > Publishing Schedule (too long?)

Admin > Site Messages
Is this the Event Log viewer? If so I say we go with Admin > Logs

Reports > Installer History
I’m thinking we could put this in as an extra tab under the Event Log Viewer/Logs, what do you think?

Great progress though. And I’m not being overly critical but I think that this is very important to usability and making new users comfortable in the manager from the get-go. I’m not married to any of these ideas either, it just never hurts to stir the waters a bit.