r3798, r3809, r3817: Don't Panic

Gocom · 2012-06-08 13:33:56

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. So option is really whether it’s this mockup or the previous one which I give Stef the enviable job of making happen.

That’s way, way, way better. Those editing forms on Links and Users pane look awful and so freaking confusing. In my opinion it’s either that (maybe even more simplified form) or the side panel layout. Editing form on top of the table — kill it with fire. Quick, before it spreads.

philwareham · 2012-06-08 14:12:20

@colak

I’ve added that to the mockup now, whether Stef implements it or not is another question though.

philwareham · 2012-06-08 14:19:34

@Gocom

I’ll make note of your comments (and I agree) about the edit forms on links and users page. I’ll see if Stef wants to do something about putting those on separate pages as part of phase 2 of the admin improvements, making them consistent with every other page.

I’m hoping that it will be relatively straightforward after that to turn those edit forms into AJAX modals (and possibly make the pophelps modals too for that matter) – it would be brilliant to get modals into 4.5 but I think it’s going to be too much work given the timeframe and other changes already planned.

Last edited by philwareham (2012-06-08 14:20:14)

phiw13 · 2012-06-08 14:29:21

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.

me likes :-) simplicity rules.

(Especially if those edit forms become ajaxy overlays or similar, this workflow becomes much more functional)

I’m hoping that it will be relatively straightforward after that to turn those edit forms into AJAX modals (and possibly make the pophelps modals too for that matter)

Oh yes, those help and tag builder pop ups as overlays… Would make working on a handheld devices / tablet easier. I fully agree with Gocom about the users and links panes, btw.

philwareham · 2012-06-08 14:40:13

Great! I’ll let Stef know what he needs to aim for (the last mockup).

I already have a demo of Textpattern modals that works well across desktop, tablet and smartphone. The major stumbling block was off-site content (i.e. pophelps) since they could not be brought in via AJAX due to cross-domain security, and iframes are effectively broken in iOS (I dislike iframes anyway). I think Jukka has a solution to that problem (using JSON?).

Anyway, I’ll try to get Stef to liaise directly with you on that as I’m not a programmer myself. It may all be horrendously complicated to achieve – I’m sure he’d be open to some extra help in that regard.

Gocom · 2012-06-08 16:30:22

philwareham wrote:

The major stumbling block was off-site content (i.e. pophelps) since they could not be brought in via AJAX due to cross-domain security, and iframes are effectively broken in iOS (I dislike iframes anyway). I think Jukka has a solution to that problem (using JSON?).

I did mention a solution using JSONP. So, yes loading those pophelp’s using JavaScript and customizing them freely on the client’s/Textpattern’s end is possible.

Using actual, (technically safer) JSON isn’t really possible, because of cross-domain policies as you, Phil, note. JSONP refers to method where script is loaded from offsite and executed, overcoming the limitations. That script contains an same data as a JSON file would, but the data object is wrapped in an named object (variable or function) making it accessible after execution.

As I mentioned in the post I linked, the RPC server would respond with some JavaScript. I.e.

txpRPC_pophelp({
	"title" : "Article Body",
	"lang" : 'en-gb',
	"body" : 'The main content of an article is contained within the article body.\n\nWhen composing or readying articles for publication in Textpattern, you can switch between three views of the article: plain text, XHTML (the code with which a web browser renders the article), and a rendered preview.'
});

That uses a function opposed to the variable I mentioned earlier, but both do the same thing. The txpRPC_pophelp ideally would be a dynamic callback function picked from HTTP GET parameter named callback. This to avoid name collisions and to be able to use jQuery’s random callback function feature, but it can also be hard-coded (probably).

The JSONP file offered by RPC server can then be loaded using a <script> tag, which makes it available on the client’s end. jQuery offers build in single-line way of handling JSONP.

$.getJSON("http://rpc.textpattern.com/help/?item=body&language=en-gb&type=jsonp&callback=?", function(data){
	alert(data.title + ': ' + data.body);
});

Last edited by Gocom (2012-06-08 16:44:51)

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)

Textpattern CMS

Textpattern CMS support forum

#31 2012-06-08 13:33:56

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

#32 2012-06-08 14:12:20

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

#33 2012-06-08 14:19:34

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

#34 2012-06-08 14:29:21

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

#35 2012-06-08 14:40:13

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

#36 2012-06-08 16:30:22

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

#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

Board footer