r3798, r3809, r3817: Don't Panic

ruud · 2012-06-08 18:26:39

philwareham wrote:

OK, another mockup based on latest comments. Edit form would be a separate page like it already is on images/files/categories pages.

Lovely!
One question though (two actually): On the left side there are edit + view links and the section name itself is clickable as well… where does clicking the section name lead to? Would it be possible to pull the edit and view links a bit further apart to avoid accidentally clicking view instead of edit (or is it just me suffering from inaccurate click syndrome?)?

philwareham · 2012-06-08 19:01:24

@ruud

Hmmm. This is probably something I need to bring up with Stef – looking at other parts of the admin-side for guidance on this I’ve noticed UI inconsistency in how items are clicked on for editing.

For example:

On the articles list you can click on the article title or id to edit, plus if the ‘show detail’ toggle is checked you can also click on the ‘edit’ link to do the same
On images page, the 2nd column always contains an ‘edit’ link, but you can also click on the ‘name’ column or ‘thumbnail’ column to do exactly the same
On files page, the 2nd column always contains an ‘edit’ link, but you can also click on the ‘name’ column to do exactly the same
On links page, the 2nd column always contains an ‘edit’ link, but you can also click on the ‘name’ column to do exactly the same
On the comments list you can click on id to edit, plus if the ‘show detail’ toggle is checked you can also click on the ‘edit’ link to do the same
On users page, the only way to edit is via an ‘edit’ link in the 2nd to last column
On plugins page (OK this one is more logical in this instance) edit link is part of the ‘manage’ column

Seems to me we need to settle on a consistent way to link to the edit screen on all these (something WordPress does well I feel). My gut feeling is to always show the edit link in 2nd column on all these list pages, maybe apart from plugins one, regardless of any ‘show detail’ toggle.

Gocom · 2012-06-08 20:42:36

If you were to ask me, I would always aim making the table rows a single line, or that the would use only a single line if window fits. The vertical Edit/View links looks pretty ass if you ask me. On most situations the Edit link isn’t needed and shouldn’t be needed at all. If everything else is doomed, I would at least make the <li>’s to spread on single line if possible. Way to spend time when Z-day comes.

philwareham · 2012-06-08 21:14:37

Well that’s an option too. All those tables have a way of getting to the edit screen without needIng an extra edit link specifically. Less clutter is always good.

Last edited by philwareham (2012-06-08 21:15:18)

philwareham · 2012-06-09 08:47:11

Actually looking at my initial Txp5 work from last year, I’d already removed the edit links and improved the table layout…

Txp5 article table

I’ll see how much of that is transferrable to Txp4.5.

Last edited by philwareham (2012-06-09 08:47:36)

colak · 2012-06-09 10:03:58

philwareham wrote:

Txp5 article table

Looking at that, there is a slight semantic problem with the comments which they indeed could be On or Off but also Expired or Closed

philwareham · 2012-06-09 12:26:05

colak wrote:

Looking at that, there is a slight semantic problem with the comments which they indeed could be On or Off but also Expired or Closed

Er, what? That’s exactly how it is in Txp4.4.1 as well. I’ve added in an ‘expired’ to the mockup just so you can visualise it now but I’m not sure I follow what you are saying.

uli · 2012-06-09 12:34:19

I saw you’ve also added a divider, a thing I’ve missed before. My idea at that time was moving the comment count to the left, thus it became a divider. If the the verbal count indicator None would be changed into a numeric one, too, i.e. (0), the pipe character would be superfluous.

philwareham · 2012-06-09 13:27:40

@uli

OK, changed now. We could probably lose ‘manage’ text entirely and make the link to manage actually on the comment count itself, what do you think?

Last edited by philwareham (2012-06-09 13:28:01)

colak · 2012-06-09 13:27:46

philwareham wrote:

Er, what? That’s exactly how it is in Txp4.4.1 as well. I’ve added in an ‘expired’ to the mockup just so you can visualise it now but I’m not sure I follow what you are saying.

Hi Phil

In txp 4.4.1 the comments in the articles tab are On, Off or expired (if the time duration for comments in the prefs is passed).

I understand that these mockups might be used from the devs and I mentioned it so as to adjust that column accordingly.

philwareham · 2012-06-09 13:30:04

@colak

Since we are removing hard-coded width attributes from columns soon in SVN, that is not an issue – column will adjust to whatever content is in it. Cheers.

Last edited by philwareham (2012-06-09 13:30:21)

Bloke · 2012-06-09 18:21:27

Wowzers! I disappear for a week and things go galactic: I’ll have to vacation more often :-)

Phil’s latest Sections mockup looks great. I’d been stuck in a redesign funk with that one, so I’m glad of the new direction. It’ll take some doing, but if everyone’s on board with this kind of layout I’ll give it a shot for v4.5. Aside from the fact that sed_section_fields will unceremoniously crawl into a corner and whimper, one sticking point is the removal of the Selected by default. Whle it seems easy on the surface from a UI perspective, this is handled horribly in the database. What should ideally happen is to remove the is_default column entirely and introduce a pref for it. It could be handled as it is now and make the pref just update every row in the database, but it’s really just postponing the inevitable table change.

For the SQL geeks among you, we can’t very well drop the column without backwards compatibility problems so the (sort of) obvious solution is:

rename the table to txp_sections and drop the column
introduce a MySQL View called txp_section to fake the old table structure

Just for a laugh I did this in my dev branch last week and it works well… but (there’s always a but) aside from the fact that Views are horribly inefficient — even as a temporary measure — it relies on the MySQL user having Show Create View and Create View permissions on the database. If they’re not available on upgrade, then everything falls apart because the admin side expects the txp_sections table to exist when it might not and, well, it all blows up in an error message soup and no admin side displayed.

So this is a philosophical set of questions / straw polls really:

Can we reasonably rely on this functionality to be present (perhaps stipulated as a prerequisite)?
Are some hosts conservative on MySQL permissions and/or refuse to allow people to change the privs?
Would we be shooting our legs off to use Views this way?
If so, is there a better way to make table changes backwards compatible?

Or should I just leave the horrible column in txp_section and work around it with the pref? This kind of thing is going to crop up as other tables are normalized over time so it’s going to rear its ugly head again and I’d like to find the best migration path.

Other than that — and apologies if your eyes glazed over when reading the previous techie paragraphs — thanks for all the feedback and ideas so far. Phil’s drafted me a tonne of changes for phase 2-slash-phase-one-and-a-half so I’d best get my skates on.

Onwards and upwards.

Last edited by Bloke (2012-06-09 18:22:26)

Textpattern CMS

Textpattern CMS support forum

#37 2012-06-08 18:26:39

Re: r3798, r3809, r3817: Don't Panic

#38 2012-06-08 19:01:24

Re: r3798, r3809, r3817: Don't Panic

#39 2012-06-08 20:42:36

Re: r3798, r3809, r3817: Don't Panic

#40 2012-06-08 21:14:37

Re: r3798, r3809, r3817: Don't Panic

#41 2012-06-09 08:47:11

Re: r3798, r3809, r3817: Don't Panic

#42 2012-06-09 10:03:58

Re: r3798, r3809, r3817: Don't Panic

#43 2012-06-09 12:26:05

Re: r3798, r3809, r3817: Don't Panic

#44 2012-06-09 12:34:19

Re: r3798, r3809, r3817: Don't Panic

#45 2012-06-09 13:27:40

Re: r3798, r3809, r3817: Don't Panic

#46 2012-06-09 13:27:46

Re: r3798, r3809, r3817: Don't Panic

#47 2012-06-09 13:30:04

Re: r3798, r3809, r3817: Don't Panic

#48 2012-06-09 18:21:27

Re: r3798, r3809, r3817: Don't Panic

Board footer