[2.0/serendipity_event_freetag] use like categories

[bernd_d]

I don't know if following idea is easy to include or if there are lot of things to change in 2.0 and/ore freetag. If it is, ignore this thread...

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.

[yellowled]

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.

YL

[Timbalu]

Though the popup solution looks good and is technically well done, I am not really satisfied with this popup. For me, tagging an entry and the entry itself is something that belongs together. You have to see your content written, to tag the words you really want.

Well ok, its not a problem if you only tag one or two words, but this is not the case everywhere.

"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.

We should at least re-think this.

[yellowled]

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.

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.

Depending on factors like screen resolution, other plugins installed, whether you use the extended entry etc., you will never be able to do that (and have never been), not even in 1.x. There is no layout option in which you can assume that this will always be possible. It might work on a specific desktop resolution, but that does not make it the perfect solution for any resolution or device.

I realize that this might be tough to use for people who use a looooot of tags. Then again, any interface is going to be tough for those people at some point. Also, please note that this is not final. It still needs some CSS work that I have put off until we have a backend mechanism to have seperate CSS/JS specific to a plugin for 2.0.

YL

[bernd_d]

You have to see your content written, to tag the words you really want.

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.

"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

"Wordpoets" can't remember what they have written five minutes before or even don't re-read it before they publish the posting?
With the old solution you always have to scoll up and down, which isn't even better.

[Timbalu]

You don't need entryproperties to have a freetag block underneath extended entries with pre 2.0 releases. Yes, it was not ideal, but scrolling could be done easily with the mousewheel, just a slight move with your forefinger. Therefore you could live with it. But this popup solution has moved far further in handling. 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. Thats all. "Wordpoets" need to see their "words" to be Poets! I would love Serendipity taking care about Artists!

[yellowled]

Yes, it was not ideal, but scrolling could be done easily with the mousewheel, just a slight move with your forefinger.

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

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.

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

I like what you're getting at, though. The entry editor is a vital part of the backend, it's probably the part of the backend people use most often. It should be customizable, just like a good text editor can be customized. It would be awesome if people could maybe drag and drop elements of the entry editor and arrange them the way they see fit.

Or just change some settings in an options page for it to move elements around. Don't use the extended entry? Just don't emit the extended entry editor at all. Use the plain editor, but never use those markup buttons? Just remove them. (I'd be the first to use that, actually.) It's a great concept.

However, not easy to accomplish. You'd have to account for any plugin that “hooks into” the entry editor. You'd have to think about layout across resolutions, usability across devices etc. I don't see this happening in this iteration of the backend unless we want to postpone release a few months.

YL

[Lux]

Hi!

I don't like the current solution.

It might work if you only use a couple of tags, but in my blog the tags are shown on more than one screen page (even on a 1920x1200 monitor). The usability unfortunately is not as good as it could be.

Please spend a minute on thinking about use cases for a new blog article.

It looks much better than it was before, but it is much more clicking and scrolling to set the options you need.

• 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 ...

Maybe it would be an option to use keyboard shortcuts.

Cheers

Dirk

[yellowled]

I don't like the current solution.

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.

Please spend a minute on thinking about use cases for a new blog article.

Please spend a minute on thinking that we may have spent way more than a minute on this backend.

It looks much better than it was before, but it is much more clicking and scrolling to set the options you need.

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.

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.

• 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 ...

* 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

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

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.

YL

[Lux]

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.

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.

The usage differs.

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.

Maybe you get the point.

* 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

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.

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

No reason not to believe you. I use it since the early beta days and I do not get used to it.

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.

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.

Maybe it would be an option to ask an usability expert to judge the new backend.

Cheers

Dirk

[garvinhicking]

When I installed 2.0 for a friend last week who wants to use the tags, I also needed to get myself comfortable with the new place. I didn't find it immediately.

IMO placing the icon at the top is something we didn't previously advocate, plugins always only ever had their place in the "Extended..." section.

Maybe placing this list/button inside that section would be better for users to find those tags again. At first I thought, the plugin wasn't installed. Otherwise, we'd at least need a "assigned tags..." display similary to the currently "assigned categories" picker.

Having said that, I must say I like having the tags as a popup. The more tags you have, the more cluttered the view will have been previously. However, maybe it's better to have the list of available tags below the input area instead of above it, so that you can always type the new tags without needing to scroll to the bottom?

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.

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]

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.

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.

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.

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.

Another idea would be to just enlarge the dimensions of the overlay windows. Not sure that will offer much of a solution, though.

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?

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.

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?

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.

YL

[Lux]

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.

I agree with that, nevertheless I think we could roughly say which settings makes sense for what device.

Writing articles has a different audience from people reading articles, device-wise.

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?

Good idea.

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.

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 main focus for the frontend should be to have it well structured and readable on any device.

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.

The tag list beforehand had a better usability - at least for me - than the recent one.

Another idea would be to just enlarge the dimensions of the overlay windows. Not sure that will offer much of a solution, though.

No, the problem is not the size.

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?

About 40 categories and 230 tags. (Yes, the blog is nine years old).

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.

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?

You did not get me. Just add more than a screenful of tags and you will see what I mean.

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.

Totally agreed. This was not the point, I was talking about.

But, the idea is not bad, ordering the tag by usage count could be an option.

Cheers

Dirk

[public s9y]

I like the popup-solution and miss a metadata-button. Having it optional (popup or inline) would be nice. I think it's easier to have it neither/nor than a mixed solution.

I too like the save-button on top of entry-editing (and miss a cancel-button), even though it's the only section with this place, as far as I saw. Maybe having them on top _and_ bottom (or optional) could be another solution.

[yellowled]

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.

Well, unless the backend accommodates for smaller screens, people will never start using it on smaller screens in the first place.

Yes, it is highly unlike that anyone will ever write a longer blog post on a smartphone. Then again, we don't have the data to validate the assumption that most users write long text-based posts at a desktop computer with a minimum resolution of AxB anyway.

The tag list beforehand had a better usability - at least for me - than the recent one.

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

YL