
Currently, tags are only available within extended entry-properties at the end of the editor. Would be awesome to see them like categories are used in 2.0 with an popup-button at the top of the editor.
I actually like the idea. The categories are kind of hidden in the extended entry options. We could add the same button/popup mechanic like for categories. I'll open up an issue for this and see if I can implement this in a usable way.bernd_d wrote:Currently, tags are only available within extended entry-properties at the end of the editor. Would be awesome to see them like categories are used in 2.0 with an popup-button at the top of the editor.
That's neither a con argument nor meant to avoid discussion, but you could not have done that with the interface we had for it in the 2.0 backend before, either.Timbalu wrote:Now you have to know/remember the words you want to tag, or go the "multipopup" way, open tag save close reopen tag save close etc.
The solution we have had before (without popup) even was not better. You didn't see your posting, because the tags have been very far down within extended entry properties.Timbalu wrote:You have to see your content written, to tag the words you really want.
"Wordpoets" can't remember what they have written five minutes before or even don't re-read it before they publish the posting?Timbalu wrote:"Wordpoets" do use that differently and then this is not really possible with the current solution. Now you have to know/remember the words you want to tag, or go the "multipopup" way, open tag save close reopen tag save close etc
Again, this not meant as a counter argument – but this is an assumption about people's way of using the backend that we shouldn't make any longer. It assumes that the user is using a mouse with a scroll-wheel. Most of the time I use the backend, I don't even use a mouse, I use a trackpad. Other people might prefer navigating the backend with the keyboard or on a device which doesn't have a mouse or a trackpad. Some people just don't like to scroll. (I'm not saying your objection is not valid, just try to not only see this from a desktop user's perspective.)Timbalu wrote:Yes, it was not ideal, but scrolling could be done easily with the mousewheel, just a slight move with your forefinger.
Just for the record – the freetag output was always within extended entry properties, even in 1.x. Right now, there's two options – you can either have the tags in a popup overlay (default) or in extended entry properties (just like categories).Timbalu wrote:I still like it, but I think there should be an option to integrate freetags between body and extended textarea instead, or append it to end as done before, for all people needing this any closer.
Let me preface this by saying that it is impossible to build one single backend design that every user will like. That being said, this solution is not set in stone.Lux wrote:I don't like the current solution.
Please spend a minute on thinking that we may have spent way more than a minute on this backend.Lux wrote:Please spend a minute on thinking about use cases for a new blog article.
None of this is (purely) about how it looks. We didn't opt for these overlay windows because they look fancy or because they are “modern” or whatever. We opted for them because they unclutter the UI of the backend.Lux wrote:It looks much better than it was before, but it is much more clicking and scrolling to set the options you need.
* you only have to click metadata once; it will save the open/close stateLux wrote:
- set as draft (oh, in 2.0 I have to scroll and click metadata to set it to draft mode)
- set category (new overlay appears, I have to scroll to see all categories)
- set tags (same as category)
- set publishing date in the future (same as draft), no calendar overlay ...
I agree, but I see a tendency to make it best for mobile users and second best for workstations users. This is the best way for readers of the blog, but it is different for authors. So, there is the big difference in understanding and usage.yellowled wrote:That is especially important given the responsive nature of the new backend. This is supposed to work on all the new devices and screen resolutions that come with them. It's next to impossible to do that without some sort of compromise.
So, for every action I have to switch between keyboard and mouse and I have to use both input methods to do it somewhat efficient. There is a gap as well.yellowled wrote: * you only have to click metadata once; it will save the open/close state
* there is a quicklist filter for categories
* there is autocompletion for tags
* if you don't get a calendar overlay, that's because your browser doesn't support the datetime input type (yet); we opted to not polyfill that because it's a lot of (JS) overhead
No reason not to believe you. I use it since the early beta days and I do not get used to it.yellowled wrote:I'm not saying that all of this is perfect for everyone. It isn't, but it never will be (see above). This new backend is going to take some getting used to (believe me, I have experienced that myself working with it).
This is so easy to test, just insert a set of dummy categories and tags so your list fills more than one screen. Some tags or categories should not be visible at once.yellowled wrote:That being said, I'm open to suggestions as to how to accommodate users with a lot of tags better. I don't use a lot of tags myself, so it's hard to imagine what would actually improve this.
That is actually the initial point which I always assumed for usage. Not any feature of the backend will be usable on smartphones (or tablets, for that matter). However, I don't think that should mean that those features should be unusable on those devices in favor of desktop computers, either.Lux wrote:I would never write a longer blog article with my smartphone, but I can imagine to do so with a tablet (I do not own one). Just different use cases.
I don't see a feasible way to make a quickfilter which can be used with a mouse without wasting even more screen real estate.Lux wrote:So, for every action I have to switch between keyboard and mouse and I have to use both input methods to do it somewhat efficient. There is a gap as well.
How do we determine which tags or categories should not be visible? How do we determine which number of tags or categories shown is appropriate on which device/resolution?yellowled wrote:This is so easy to test, just insert a set of dummy categories and tags so your list fills more than one screen. Some tags or categories should not be visible at once.
I agree with that, nevertheless I think we could roughly say which settings makes sense for what device.garvinhicking wrote:Other than that...yellowled is right - asking 10 people about this will yield 11 different opinions on how it should work best. I think the current approach is on a good track.
Good idea.garvinhicking wrote:On the other hand, we'd always have the option to create a new config option in the plugin to indicate [x] use inline display for freetags?
yellowled wrote:That is actually the initial point which I always assumed for usage. Not any feature of the backend will be usable on smartphones (or tablets, for that matter). However, I don't think that should mean that those features should be unusable on those devices in favor of desktop computers, either.
The tag list beforehand had a better usability - at least for me - than the recent one.yellowled wrote:I don't see a feasible way to make a quickfilter which can be used with a mouse without wasting even more screen real estate.
No, the problem is not the size.yellowled wrote:Another idea would be to just enlarge the dimensions of the overlay windows. Not sure that will offer much of a solution, though.
About 40 categories and 230 tags. (Yes, the blog is nine years old).yellowled wrote:Could you give me a rough estimate of how many categories and tags you're using so I have a rule of thumb as to what numbers we might be dealing with here?
You did not get me. Just add more than a screenful of tags and you will see what I mean.yellowled wrote:How do we determine which tags or categories should not be visible? How do we determine which number of tags or categories shown is appropriate on which device/resolution?Lux wrote:This is so easy to test, just insert a set of dummy categories and tags so your list fills more than one screen. Some tags or categories should not be visible at once.
Totally agreed. This was not the point, I was talking about.yellowled wrote:I'm not saying this is a bad idea – in fact, it could be a solution. I'm just saying, there's more to think about here. I can't just build something which works for a desktop user with X categories and Y tags, there are more scenarios to think about.
Well, unless the backend accommodates for smaller screens, people will never start using it on smaller screens in the first place.Lux wrote:Correct, but when most people use a "bigger screen" for writing articles or using the backend in general, this should be the main focus for the backend.
The only differences between the tags lists in 1.x and 2.x are that it is always visible in 1.x and has a smaller font-size. The latter is definitely not better for usability, so what you're saying is you don't like that it's in an overlay window? (Which, by the way, can be disabled, although that seems a little buggy as I just noticed.)Lux wrote:The tag list beforehand had a better usability - at least for me - than the recent one.