Hive 4.6 and beyond

hcgtv · 2016-09-11 11:58:44

Good morning Devs,

Lovely morning here in Miami, Florida, it’s sunny, hot and humid, like always, you just sweat, bring plenty of white t-shirts. I’m on my second cup of coffee, recovering from the wild release party ;)

Now that 4.6 is out the door, and I’m using it on live sites, my admin-theme:

Write panel:
- Menu down the left side like the Presentation tab.
  - Feels awkward switching from Content to Presentation.
- Recent articles on top, where the Sort and display is.
- Too many collapsible items.
  - Text formatting help could be made a popup.
  - Article image all alone in it’s own widget, pray tell.

Presentation tabs:
- The location of the Save button is reducing the life of my mouse wheel.
- Textarea lengths should try not to exceed the height of the browser window.
  - The dreaded dual scrollbars, mouse wheel giving out by now.
- Form name and Form type on same line, bring the textarea up, align it with the side menu if possible.
- Larger fonts for the seeing impaired brought on by father time.

Overall, Hive is a much better experience from the 4.4.1 days. At this point it feels that backwards compatibility with admin-side plugins is holding back taking the admin theme much further. Also, the backend deserves a Desktop and Mobile theme, trying to appease both in one theme does neither side any good.

Now where’s that bottle of aspirin?

Bloke · 2016-09-11 13:37:15

hcgtv wrote #301320:

Recent articles on top, where the Sort and display is.

I don’t use that sub-panel, but when we roll in drag ‘n drop you’ll be able to move it where you please.

Text formatting help could be made a popup.

Agreed. Will investigate options.

Article image all alone in it’s own widget, pray tell.

It didn’t seem to fit elsewhere, but the longer-term idea is that when we go to a grid view for the Images panel, we’re rewriting the way it draws that panel. Then — against my better judgement because it’s likely to polarise the community — we can roll in the ability to pick images to attach to an article. And at the moment, keeping it as a separate panel gives plugin authors a nice blank canvas to do likewise.

The location of the Save button is reducing the life of my mouse wheel.

See drag ‘n drop comment above.

Textarea lengths should try not to exceed the height of the browser window. The dreaded dual scrollbars, mouse wheel giving out by now.

This I agree with. Especially if your window is just thin enough to trigger the sidebar to relocate above/below the textarea. Under these conditions, if you mouse wheel down to get to the Save button and have a long Page template (or big plugin on the Plugins panel) you end up scrolling the textarea instead, and only when it hits the bottom does it continue to scroll the page. Otherwise, the only other option — short of tabbing out with the keyboard and using the arrow keys — is moving the pointer to the sliver of real-estate between the textarea and the window edge and scrolling there to reach the bottom.

It doesn’t just affect Textpattern, but it’d be nice to address it somehow. I’m not sure how, though.

Form name and Form type on same line

Worth looking into, and collapsing it like it is now on thinner screens. If you have the desktop width, I’d use it. But I’m not a designer so it’ll be up to the UX experts.

the backend deserves a Desktop and Mobile theme, trying to appease both in one theme does neither side any good.

I prefer a unified approach as it’s less code to maintain, but I know plenty of website owners that have tried it and moved away to dedicated mobile. That’s for front-of-house websites; I don’t know any that separate things for a back-end admin-side system. Not that it’d be intrinsically wrong either way. Maybe it was because they simply weren’t good enough at responsive design(!), but feel free to hack. We certainly need more themes, and a place to showcase them with the demise of TextGarden (themes.textpattern.com, one day? Maybe when we officially support front-of-house themes too, we can use that subdomain for both?)

fwiw, smd_admin_themes is next on my hit list so there’ll be no excuse for anyone not to come up with their own.

hcgtv · 2016-09-11 15:37:51

Bloke wrote #301322:

See drag ‘n drop comment above.

That maybe years away. I’ll play around, see what I can do, compare the 4.6 admin-themes.

I prefer a unified approach as it’s less code to maintain, but I know plenty of website owners that have tried it and moved away to dedicated mobile. That’s for front-of-house websites; I don’t know any that separate things for a back-end admin-side system. Not that it’d be intrinsically wrong either way.

Many front-of-house websites are going totally mobile and I understand. For an admin-side, going mobile means either an iOS or Android app, or a dedicated theme. I can’t see how you can please both desktop and mobile users with one theme, they’re just so disparate interfaces.

I understand trying to keep things as backwards compatible as possible, especially when it comes to admin-side plugins. I get it, just don’t agree.

philwareham · 2016-09-11 16:37:39

Ok let’s open the discussion: please explain to me what a desktop and mobile theme actually is, and how you go about testing for that?

Do you go by screen width? If so what screen width? A Galaxy Note is a mobile, is an iPad a mobile? What about an iPad Pro?

Do you go by touch (which can’t be tested reliably anyway)? If so does a Surface Pro qualify as mobile? How about those touch enabled laptops?

Then perhaps tell me how supporting all screen widths negatively impacts your desktop experience and vice versa?

I agree an app would also be valuable in addition to what we have currently, If someone (maybe you) wants to provide one I’d be very happy with that.

hcgtv · 2016-09-11 17:26:43

philwareham wrote #301327:

Ok let’s open the discussion: please explain to me what a desktop and mobile theme actually is, and how you go about testing for that?

Ok, let’s go…

You don’t test for it like you would a front facing theme, you pick it.

I’m in Desktop mode, or I’m in Mobile mode. If you’re on an iPad pro, or whatever device you think can handle the Desktop mode, then go for it.

In Desktop mode, we can have more widgets, different placement and sizes of textareas, the menus might be somewhere better placed for mouse movement. In Mobile mode, less to deal with, a simpler interface, buttons and menus better placed for touch..

Yes, drag and drop, shade mode on elements, etc, but you’ll still need desktop and mobile profiles to save your preferences.

philwareham · 2016-09-11 17:58:32

Sure, but who says what widgets don’t make the cut for mobile (whatever mobile means)? One persons useless widget is another persons valuable feature.

Don’t you think a better approach is a customisable admin side like we already want to do? If that had different profiles you could save depending on your workflow then all the better.

The textareas I’ve tried to strike a balance between large screens and small. I implemented auto resizing textareas in the write page but that doesn’t necessarily work for code areas after testing.

The text filter help we are already planning to move from the side menu in a similar way to how tag builder was done.

philwareham · 2016-09-11 18:18:40

I don’t understand why drag and drop would be years away either, since we already have jQuery UI in 4.6. One of the features being programmable drag and drop. It just needs someone to code it in – but that also goes hand in hand with custom field changes that I think Stef has already started to experiment with.

I can investigate during 4.7 work in terms of visual usability.

hcgtv · 2016-09-11 19:24:10

philwareham wrote #301336:

I can investigate during 4.7 work in terms of visual usability.

I’ll roll my own theme, every time I have to mouse wheel down to hit the save button while working on a form, adds to my anxiousness.

mrdale · 2016-09-12 00:57:18

I would like to revisit the multi edit action links being moved or duplicated to/at the top of the page 1) where they are most often found elsewhere and 2) where they do not require a page scroll for every action on longer lists.

…of course this is somewhat moot if you’re making the whole interface drag and drop.

phiw13 · 2016-09-12 06:26:10

hcgtv

Textarea lengths should try not to exceed the height of the browser window. The dreaded dual scrollbars, mouse wheel giving out by now.

At a personal level, it is not so difficult to fix, if it really bothers you. In the custom stylesheet (check the README of the theme of your choice), insert the following:

.code { max-height: 90vh; }

Increase, or decrease the value depending on how much more of the page you want to show. 100vh equals 100% of the viewport height.

Bloke

This I agree with. Especially if your window is just thin enough to trigger the sidebar to relocate above/below the textarea.

That is actually quite a difficult issue to resolve across the board. People have all kind of window height, and so on. The code above is probably OK for someone like Bert who has largish / tallish window (full screen etc, if I understood correctly, 1920×1080 laptop). For me it would already result in a textarea that is rather smallish on the height side, and too small to work comfortably. One way around is to specify a min-height that is tall enough, but not too tall to get in Bert’s way (where do you decide the cut?). min-height trumps everything else, always. Added difficulty, Textpattern specifies a height (row=32 attribute), the computed value of which depends on the font-size (that explains the difference he mentioned here between Hive and Sand space).

Bloke

[…] — short of tabbing out with the keyboard and using the arrow keys —

one press of the tab key should focus the Save button on the Pages and Forms panels. Just saying…

phiw13 · 2016-09-12 06:33:40

mrdale wrote #301345:

I would like to revisit the multi edit action links being moved or duplicated to/at the top of the page 1) where they are most often found elsewhere and 2) where they do not require a page scroll for every action on longer lists.

1. I’m slightly puzzled here – do you never (need to) scroll down first to access the items-to-edit of your choice? (genuine question… You already know my POV from our previous discussion)

2. curious if this interface would suit you (disable you current hack before trying):

.multi_edit_form {
	position: relative;
}
@supports (position: sticky) or (position: -webkit-sticky) {
	.multi_edit_form .multi-edit {
		position: -webkit-sticky;
		position: sticky;
		bottom: 0;
		background: hsla(55, 1%, 99%, .95);
		padding: .214286em 0;
		box-shadow: 0 -10px 10px -5px hsla(0,0%,100%,.95)
	}
}

That will position the multi-edit widget at the bottom of the tables like now, if there are only few items. For taller tables, the widget will “stick” to the bottom of the viewport and always be visible while you are scrolling through. You need Firefox or Safari for this though. You can also try this mockup.

Last edited by phiw13 (2016-09-12 06:34:08)

jpdupont · 2016-09-12 07:39:53

Philippe,

Great, for my opinion !

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-11 11:58:44