Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

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

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?)?

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

@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:

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. On users page, the only way to edit is via an ‘edit’ link in the 2nd to last column
  7. 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.

Offline

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

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

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.

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

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)

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

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)

Offline

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

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,062
Website GitHub Mastodon Twitter

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

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


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

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.

Offline

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

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,306

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

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.


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

@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)

Offline

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

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,062
Website GitHub Mastodon Twitter

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

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.


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

@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)

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,410
Website GitHub

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

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:

  1. rename the table to txp_sections and drop the column
  2. 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:

  1. Can we reasonably rely on this functionality to be present (perhaps stipulated as a prerequisite)?
  2. Are some hosts conservative on MySQL permissions and/or refuse to allow people to change the privs?
  3. Would we be shooting our legs off to use Views this way?
  4. 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)


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

Board footer

Powered by FluxBB