Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: r3798, r3809, r3817: Don't Panic
I would just drop the column. That’s right, I wouldn’t do anything else. Simply dropping the column really shouldn’t break anything horribly and those things that do break, can be fixed very easily. It’s just a column. The change is very minimal.
Other option is to leave the column there, but mark it deprecated in release notes and documentation. Keep the column updating in place for now. This gives everyone time to migrate and change the ways. When the next release comes this column and the old updating code is removed. If someone didn’t update their code, then it’s their problem as far as Textpattern is concerned.
As the question about MySQL permissions go, normal day-to-day Textpattern operations would be best if kept in update, insert, show and delete. While this I’m not referring to limitations set by hosts, it’s true that many hosting providers limit user permissions (for reasons, including resource usage).
Last edited by Gocom (2012-06-09 18:53:17)
Offline
#50 2012-06-10 12:45:42
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,306
Re: r3798, r3809, r3817: Don't Panic
philwareham wrote:
We could probably lose ‘manage’ text entirely and make the link to manage actually on the comment count itself, what do you think?
Yes, I think it’d be really intuitive enough. As it’s always a little hard to quickly hit one-digit numbers I’d wrap the whole cell content into an anchor tag, regardless of whether comments are turned on or off: someone might want to manage comments after turning them off.
While I’m at it something crosses my mind: It’d also make sense to display here an indicator for comments awaiting moderation. It’d probably best be represented by the count of these comments. Could be On (3/15) or more speaking On (15, 3 new). The moderate class from the comments page could be employed here.
The link to the article’s comments page might be well equipped with sort=date&dir=desc hence the newest comments (the unmoderated ones) start always above the fold when the page opens.
(Edit: BTW, the whole posting refers to this page.)
Last edited by uli (2012-06-10 15:58:33)
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: r3798, r3809, r3817: Don't Panic
Nice work Phil!
The only comments I have against the mockup iterations are more presentational, I guess…
There’s a big block of white space at top of these newer designs. In the Articles mock you see it on the right side, and it would be on the right side of the Sections mock too if the little form that’s currently center-aligned were left-aligned like it is in Articles. There’s also no “Sections” panel header like exists in Articles; the existence of which also contributes to the white space block.
So it seems there are some presentational considerations to make:
- Panel headers or not?
- Consistent alignment of top data forms. (So which way?)
- How could the white space be used more effectively?
Being this is the admin-side (not concerned about SE referencing), I think we could do without the headers and just ensure the admin-side nav elements are clearly providing the orientation cues. (Though maybe breadcrumbs are useful for admin-side?)
If you didn’t want to make any other changes, then a center alignment on the top forms (consistently) would be reasonable and just forget the white space at that point.
But if forms are left aligned, then the block of white space on the right side could be used for system feedback messages, and since they would be at top in that case, they would be easier to see. For example, you could put those faint yellow ones that you have at bottom into the top instead. But it wouldn’t just stop there, maybe you provide even more immediate feedback cues by using…
- green feedback boxes for “Success” messages (Your article was posted successfully!)
- yellow boxes for missing data messages (You did not select a new AUTHOR to change to.). Though looking at that now that’s not how it behaves, which is probably not ideal.
- red (or fire orange) boxes for error and debugging messages.
Just something to think about. Except for the one yellow feedback message in your mockups, I can’t tell what the top messages would look like otherwise, so it might be interesting to see a mock showing that too.
Lastly, Philipp had introduced the discussion idea of using PT typeface in the admin-side. I’m easy either way, but it would be interesting to at least see how PT Sans might look in a mockup, and thus make a decision about that one way or the other now.
That’s all I have.
Offline
Re: r3798, r3809, r3817: Don't Panic
Hello destry
The latest versions of core themes already have different colours depending on success, warning error. The mockup you are probably looking at is the defunct txp5 work I did last year.
Not sure Robert would be keen to include PT Serif into the download package but I’ll bring it up and see. The next SVN commit will have the 2012 logo in place anyway.
My own Hive theme, which may or may not appear in the official 4.5 release alongside the 2 existing themes, definitely won’t be using PT Serif. The front side theme already uses it – always did which is a happy coincidence.
Stef has just put page titles into a test patch at my request, but I need to evaluate whether the benefit outweighs the extra page space they would take up, and also how they would sit with existing elements.
Alert boxes will probably be moved out of the page flow, like I do in Hive theme, since now with AJAX injects Robert has added you may never see them if they are still positioned at top of page.
Offline
Re: r3798, r3809, r3817: Don't Panic
philwareham wrote:
the edit panes will ideally be moved to AJAX modals instead of new pages That modal technique will also hopefully be utilised to directly insert images into articles as you write them too.
Yes! I’ve wished many times for modals rather than pulling up a new page.
I also like the most recent mock-up the best.
The only observation I’ll make is that most of choices are yes/no or on/off. Being able to simply click once on the choice and having it change to the desired state, or in the case of selecting page/css, having a drop down, is actually more intuitive and more efficient than even a modal. In that sense, the current approach of having all sections editable, combined with the mockups new layout would be preferable for its simplicity and efficiency. just my opinion, of course :)
Gocom wrote:
I would just drop the column . . . Simply dropping the column really shouldn’t break anything horribly and those things that do break, can be fixed very easily. It’s just a column. The change is very minimal.
Ditto
uli wrote:
it’s always a little hard to quickly hit one-digit numbers
Definitely. Please avoid this when possible
Offline
Re: r3798, r3809, r3817: Don't Panic
maverick wrote:
The only observation I’ll make is that most of choices are yes/no or on/off. Being able to simply click once on the choice and having it change to the desired state, or in the case of selecting page/css, having a drop down, is actually more intuitive and more efficient than even a modal. In that sense, the current approach of having all sections editable, combined with the mockups new layout would be preferable for its simplicity and efficiency. just my opinion, of course :)
Whilist I agree in part, that would then be inconsistent with UI/UX principles used on the rest of the admin-area, something we are working hard to avoid doing.
Other than that though, I’ll make sure the links on numbers also include the brackets, to make the clickable area slightly larger – so it will be <a>(5)</a>.
Last edited by philwareham (2012-06-11 15:12:04)
Offline
Re: r3798, r3809, r3817: Don't Panic
Although I’ll probably get flamed for this, I agree (mostly) with Maverick. At least I think it’d be good if some or all of these were options so the interface can ‘grow’ with a person’s workflow as they become more comfortable with it.
While making a start on the new Sections tab earlier today I did precisely this and being able to toggle a Yes/No directly from the list is very handy. Having the Pages and Styles as dropdowns, however, did not work as well. While it was great to be able to do it directly, the sea of widgets on the screen made it very confusing and visually overloaded. So I would be in favour of the direct Yes/No but would defer other, more detailed, changes to the Edit step (where you can also alter the Yes/No state via radios before saving).
This permits three ways to effect section status changes, based on how granular you want to be and how proficient you are at building a site:
- Rapidly toggle an individual item directly from the list.
- Click a Section’s name to edit its information (which currently goes to a separate step; could be a dialog in future).
- Use the multi-edit tools to change more than one Section at once.
While I agree with Phil that we should keep consistency up, it’s no different to being able to toggle plugins on and off by clicking Yes/No links. If we were purists, we should remove that facility in the aims of keeping things consistent, thus we’d have to use the Edit step of the plugin panel to switch them on and off, viz:
- Click Plugin name
- Change enable/disable state radio
- Click Save
Instead of:
- Click Yes/No to toggle state.
In fact, making the plugin enable/disable feature an AJAX state is on our hit list of things to do because the lack of page refresh means more rapid toggling of plugins. If anything, I’d like the togglable Yes/No states to be introduced a little more on the admin side (where appropriate) so page refreshes can be minimised if you wish.
Having said all that, I will happily bow to the usability crowd of those more experienced in UI/UX design if my thoughts are way off base and would make things more confusing.
Discuss :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: r3798, r3809, r3817: Don't Panic
If you are going to introduce yes/no toggle states on list tables, just make sure you use it consistently (and only where it actually helps workflow) – in that essence, I’m all for it. Anything beyond that (like drop downs for example) – don’t put into a list table, it’ll look crap and hinder UX.
Offline
Re: r3798, r3809, r3817: Don't Panic
Bloke wrote:
Having the Pages and Styles as dropdowns, however, did not work as well. While it was great to be able to do it directly, the sea of widgets on the screen made it very confusing and visually overloaded.
I can see how that might be functional but visually unappealing.
So I would be in favour of the direct Yes/No but would defer other, more detailed, changes to the Edit step (where you can also alter the Yes/No state via radios before saving).
Sounds like a reasonable proposal to me :)
If anything, I’d like the togglable Yes/No states to be introduced a little more on the admin side (where appropriate) so page refreshes can be minimised if you wish
+1
philwareham wrote:
Other than that though, I’ll make sure the links on numbers also include the brackets, to make the clickable area slightly larger – so it will be
<a>(5)</a>.
Thank you!
Offline
Re: r3798, r3809, r3817: Don't Panic
OK, Phase 1.5 has landed in r3809. Rumblings include:
- Shifting some of the columns about (e.g. moving names/titles to the left, after ID columns).
- Removal of direct Edit links. The Edit step is now accessed by clicking the ID/name/title of the item you want to alter. That currently applies to the Articles, Images, Comments, Files, and Plugins panels. The Links and Users panels will follow the same pattern in the next Phase when they get separate Edit steps.
- Removal of direct View and Download links:
- Articles panel you can still view an article by clicking the Live/Sticky status. In addition, the Hidden, Draft, etc statuses have been upgraded so you can click on those to Preview the article.
- Images panel a [View] link has been added after the name as a temporary stop-gap. Both Phil and I agree this is pretty crap but we don’t have any great ideas about where to put it, if indeed the functionality needs to be there at all. It just opens the raw image out of the admin side and the only use for that I can come up with is being able to right-click it and save the image, which obviates the need to go grab it from your FTP client or having to visit the Edit step first. If we can live without a [View] here, let it be known. Other thoughts on this topic welcome.
- Files panel you can now download a file by clicking its download count value instead (it’s always annoyed me that it increases the download counter when you do this from the admin side, btw and I deem this a bug, but that’s a separate discussion)
- Headings have been added to all primary panels (not edit steps… yet??). While these take up a fair bit of vertical space at the moment, Phil is working on making it neater. As the various admin tabs become less distinct and more consistent, having this heading as a navigational aid will be beneficial. We cannot rely on a theme to adequately indicate wayfinding, especially since things like Remora use dropdowns which require you to hover over the menu to see which tab is active. Breadcrumb trails are not much use because every panel is only one or two steps from the ‘top’ , by design (prefs notwithstanding at the moment). The h1 tags all have a class of
txp-headingso if a theme author feels strongly about them they can be altered/silenced with one CSS rule. The Write tab is a special case because it’s an “Edit” step that happens to be directly accessible from the top nav, hence it doesn’t have an h1 (plus it would take up too much real estate for no gain: the Write tab is very distinctive as it stands already). - Tagbuilder and Plugin ‘Manage’ links have been made inline. Thoughts on whether the ‘Manage’ column is the correct terminology and/or whether the help/options links can be moved elsewhere on the panel are welcome.
- Comments panel’s Unban link has been brought adjacent to the IP address. Save a column, save the world.
- Explicitly defined HTML table widths have been removed so themes can control them if required.
txp-headerandtxp-footernames employed as containers (thanks phiw13)- The HTML
<title>element has been altered to[Panel name] - [Site name] | Textpattern CMSwhich, as well as maintaining consistent branding, helps those of us like me with 30 browser tabs open!
Next steps are:
- get rid of the combined Edit/List on the Links and Users panels. Employ a separate Edit step. You could reach that step via a ‘Create’ button to enable adding new Users/Links. I’m thinking along the lines of:
- Users: A single input box for User (login) name + a Create button. The Edit step then shows up with the name you chose filled in and the remaining boxes available for completion. The legend will make it clear that this is an ‘add’ action, and the save button will be, erm, not sure yet. Publish? Add? Create?
- Links: A single input box for the link URL + a Create button. Then proceed to the Edit step as per Users described above.
- making the layout of the UI in the Edit steps more consistent
- tackling the Prefs panel
- attacking the Sections panel (which I’ve started already)
Please keep feedback coming in.
Last edited by Bloke (2012-06-12 12:40:12)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: r3798, r3809, r3817: Don't Panic
Just to add to the next steps Stef outlined above, still also planned for improvements for v4.5 (but further off) are:
- Setup (installation) steps pages
- Login panes
- Classic theme navigation area (the tabs metaphor)
- Import pages
- Separating prefs from languages, and consolidating prefs into a single page
- Improvements for RTL languages
- Some further tweaks to edit panes for consistency
- Documentation of admin-side code structure and design pattern resources (this may slip too after release but it will be done)
The following I hope to targeted for after v4.5
- Modal windows
- Remove all remaining HTML tables that are just used for layout (there are actually very few of those now)
Last edited by philwareham (2012-06-12 13:11:56)
Offline
Re: r3798, r3809, r3817: Don't Panic
Two little bugs following r3809 (after just a quick look around):
On Presentation > Forms, why is there an empty p with (empty) span immediately after the textarea ?
On Content > Comments, uncheck the ‘details’ checkbox – the header (thead) row is missing its last cell and the previous column is missing text-label (Parent).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline