MrHaroldA
commented
8 years ago A UI for creating/editing (boolean) node properties would be cool too ... but that might be too Fields-like.
Closed jenlampton closed 8 years ago
MrHaroldA
commented
8 years ago A UI for creating/editing (boolean) node properties would be cool too ... but that might be too Fields-like.
quicksketch
commented
8 years ago A UI for creating/editing (boolean) node properties would be cool too ... but that might be too Fields-like.
sutibun
commented
8 years ago I'd like to call into question the need for this "promote" checkbox.
It seems like a feature few people actually use or maybe fully understand. (fine. maybe it's just me.)
Seems to me like
I guess I've never understood why you'd need this at all. It always confused me. (and it still does)
In the early days when first using Drupal, I always checked the checkbox before publishing a post, thinking if I didn't, my post wouldn't appear on the homepage.
"Promoted to front page?" Wait, so if I don't check this, my post won't go to the homepage? Er? ok.. I guess I have to check it from now on.
Now, when I create a View, the filter criteria is simply that it's "Published" and maybe it is a certain content type.
I wonder if other newcomers will be confused by this flag. It seems like a superfluous option. Adds more to think about before publishing a new post.
klonos
commented
8 years ago I wonder if other newcomers will be confused by this flag. ... Adds more to think about before publishing a new post.
You do have a point there, but...
It seems like a feature few people actually use or maybe fully understand.
...we need metrics in place before we use such assumptions as arguments.
klonos
commented
8 years ago My objection to this feature lies in the fact that it is some sort of a stripped-down version of a feature that perhaps should be in core (flags).
klonos
commented
8 years ago ...I honestly cannot be bothered with it (I personally choose to ignore it by always disabling the "Show option to promote posts" checkbox in the content type Publishing settings). Perhaps we should move it out of there and make it a boolean field with a single on/off widget (?). That way people can rename it to whatever suits their website or content type better. ...plus we give them an example of how they can create "custom flags" ("Ahah! ...it's that simple! All I have to do is add a boolean field. Cool!!").
docwilmot
commented
8 years ago My thoughts:
The capitals make it implied that Frontpage View is a thing, not just the display of the front page. The negation means if you feel like ticking that box, you would best go figure out what that 'View' is first, but that it is an optional thing that you can ignore because its unchecked by default.
sutibun
commented
8 years ago Flags seems like an advanced feature (even I'm still trying to wrap my head around the concept) and one that I wonder if it's used primarily by a minority of advanced Backdroppers and/or complex sites.
I am simply trying to question the assumption
Yeah, Drupal had this Frontpage flag... so, that must mean it was a heavily used feature... so, of course, Backdrop needs to have it in core. Why wouldn't it?
I want to make sure this is really something we've thought through and are going to purposefully include, enable and/or expose to Backdrop users by default.
...we need metrics in place before we use such assumptions as arguments.
That's why I boldened "seems" earlier because I am emphasizing the fact those statements are assumptions and I am unsure. Going more with intuition and feeling really. I have no direct personal experience to back me up nor numbers I've looked into. Just like with everything else I've suggested, I only have my thinking and reasoning to go with.
Though I would like to add that we shouldn't based our decisions on just metrics alone. Yes, it's a useful indicator but we also need to consider, think things out and see beyond the numbers.
First, I'd imagine the current Backdrop community is relatively small. We can't assume the community we currently have (possibly all Drupal traitors :p) will be the same as in the future. When Backdrop grows, the community demographics can easily skew elsewhere. If we plan for where the puck is now, we may miss where it's going. (can't believe I said that)
Secondly, we can't also rely 100% on the metrics from the Drupal community. Not only is it a different demographic (or should be eventually) but the Drupal community isn't really our target audience. So, how can we based our decisions on the preferences of a community we're "moving away" from?
I'd hate to go this route, (I'm just that kind of monkey) but think of the difference between Google and Apple (gonna way over generalize because I can). Google makes design decisions based on numbers and statistics. The "facts". Apple uses design thinking. It empathizes with, tries to understand its audience and then paint a vision. There were no metrics for the iPhone.
Numbers and metrics can only tell you about the past with 100% certainty. Not of the future.
so, basically, therefore, hence, and as you can all see, we need to strike a careful balance between metrics, vision, etc blah blah blah
Anyway, couldn't we strip this flag feature and relegate it to contrib module status and let it prove itself out in the wild? (assuming you guys also think it's a good idea)
My objection to this feature lies in the fact that it is some sort of a stripped-down version of a feature that perhaps should be in core (flags).
Maybe a solution is to port over the Flags module and see how it fares. It'll be a more complete solution for those that need flags.
Anyway, my two cents.
My thoughts:
- change label to 'Hide from the Frontpage View'
- change the view to exclude instead....
Huh? You, good sir, have lost me. (no need to explain)
klonos
commented
8 years ago First, I'd imagine the current Backdrop community is relatively small. We can't assume the community we currently have (possibly all Drupal traitors :p) will be the same as in the future. When Backdrop grows, the community demographics can easily skew elsewhere.
It won't be only the audience or their numbers that change... we might as well have new core features implemented that render other features useless or even obsolete or there might be new contrib modules that do that. That's why we should not have just metrics but also some sort of threshold or something like that (I don't know how to phrase this better because English is not my main language). What I mean is that if a certain aspect or feature we have metrics on suddenly "jumps" from say 50% to 80% or from 90% to 20% and then that percentage stays consistent over a month or two, then we should change things to account for the majority of users. It's the fair thing to do I believe.
Secondly, we can't also rely 100% on the metrics from the Drupal community.
The point is to get metrics in Backdrop and Backdrop.org. We cannot (and should not) rely on Drupal and Drupal.org and I doubt they will implement metrics (other than the standard project usage they already gather stats for) any time soon. See for example these issues in d.org (especially the first two that aim to help with decision making more than simply collecting stats):
Establish heuristics for core feature evaluation [#1273344] Provide means for module maintainers to collect heuristics on certain settings of their modules. [#1439316] Drupal.org should collect stats on enabled sub-modules and core modules [#1036780] Collect stats on enabled sub-modules, not just projects [#1274766] Display stats on enabled components (e.g. modules included in a project) [#1627676]
All these were filed in 2011-2012 and have seen very little action :disappointed:
The reason I am spending time (something that is very scarce in my life) on Backdrop and not on Drupal any more is because I was fed up with the long period for which many issues for either fixing important annoyances or implementing really useful features were left to "rot" in the queue. On the other hand, we had other not-so-useful features (cough f@ck you overlay cough) slip into core because some people thought would be "great for most users" without any actual data/metrics to back their decisions. And when people pointed that fact, instead of adapting and changing things they threw the familiar to all "will do it ...in D8/D9" (hint: in 5-6 years time ...till then, tough titties). Now compare the reaction time of that to the recent #1214 for example. Fine, I am a Drupal traitor ...but I feel that Drupal has betrayer me first.
Google makes design decisions based on numbers and statistics. The "facts".
That's why I love them! ...and that's why everyone uses Google search and maps for example. Yes, I am purposely exaggerating ...but here are some metrics on that:
...fair enough, I know what you are going to say: I'm using google search to make a point on a market share concerning Google. What can I do, ...everyone uses Google search :smiling_imp:
Apple uses design thinking. It empathizes with, tries to understand its audience and then paint a vision. There were no metrics for the iPhone.
No there were not. ...and that's why people believe that everyone owns an iPhone (same story as the D7 overlay.module if you ask me).
Anyways, this is turning way OT and the main point is that we should not base decisions solely on metrics but they should be taken into serious account and yes we should re-evaluate things and adapt where and when necessary. I am sure everyone agrees with that (no metrics or pretty pie charts to prove that point, sorry about that, but I have a gut feeling :smile: ).
PS: screenshots there for posterity and capturing the current status at the time of writing this.
sutibun
commented
8 years ago As I was reading your response, I felt like we're both on the same page but saying it differently.
| klonos | monkey |
|---|---|
| Gut feeling + design thinking is important BUT I find not enough people take metrics seriously before making a decision | Metrics are important BUT I find not enough people take gut feeling + design thinking seriously before making a decision |
i.e. we see equal value on both sides (unless I completely misunderstood you)
BTW, those links had a lot of useful information. Do you know if Backdrop records those kind of statistics? (enabled modules, module settings, enabled sub-modules, etc) Or plans to in the near future?
Fine, I am a Drupal traitor ...but I feel that Drupal has betrayer me first.
"Drupal traitors" hehe. Sorry, I didn't mean it as an insult. I meant it as a joke. I just meant users who came over from Drupal. (I'm one too, btw)
The reason I am spending time (something that is very scarce in my life) on Backdrop and not on Drupal any more is because I was fed up with the long period for which many issues for either fixing important annoyances or implementing
Based on those linked issues... 4 years does seem a lil' slow. ^_^
For me, I had no idea Backdrop even existed until Lullabot mentioned them on their blog. I liked Backdrop's intended audience (because that's me) and their philosophy, specifically
Backdrop values site builders over coders. It's most important that the product first be usable
So, I secretly watched the main hangouts (more recent months) and Nate won me over. I didn't know how to help out until I finally checked out GitHub and figured I could help smooth out the rough edges with my ideas.
I also feel like there's a decent chance of making things happen.
Anyway, I'll be good. I probably write a lot. I don't want to cause trouble. Really, I just wanted to confirm: "Are we all in agreement this flag feature even belongs in core?"
Or, using the heuristic question: "8. Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others?"
I personally had difficulty understanding it when starting out with Drupal. If you were tracking my usage then, the metrics would show I was heavily using it. But, in reality, I only used it because I thought I needed it so my content would appear on the front page. (Only much later did I realize that's not true)
I get the feeling this is an advanced feature best as a contrib module or not shown to users by default. Those that want flags would best be served by a module dedicated to it and comes with more options. (Because it's taken care by users who use it, they'll do a much better job developing and maintaining it than if stuck in core)
I definitely could be wrong but that's my current line of thinking/reasoning.
PS: When I said, "There were no metrics for the iPhone." I was sloppy. I meant
"Before the first iPhone was ever created, there were no metrics to guide Apple on how to build it. No metrics to tell Apple a touch interface was best or the UI they went with was the right choice."
During times like these, it requires the mind of a designer. Empathizer? Thinking things out? Gut feeling? Understanding the audience? Design thinking? I don't know what you call this but you get the idea.
jenlampton
commented
8 years ago Interesting conversations here :+1:
My original point was that we have this thing called "Promoted to front page" which most people misunderstand, or don't use. I, on the other hand, have been using this this 'flag' as a lightweight version of flag module for some time.
We do have a proven solution to this problem in contrib, but I have many sites that don't actually need flag module, because they have this checkbox in core! I find it handy to use it for various different things, but I usually end up having to form-alter it's label, because "Promoted to front page" means something too specific.
All I was proposing was that we change it's name. If we called it "Promoted" then people could use it for whatever they wanted. We could keep the existing behavior of having this box control what's on the home page (backwards compatability++) but also turn it into a useful tool for other things.
Will this do everything flag does? No. But that's why we have flag in contrib!
Does it do any harm to leave it here? I don't think so.
Would it do any harm to remove it? Perhaps? People who were using it as a flag before would now all of a sudden need a contrib module.
sutibun
commented
8 years ago My original point was that we have this thing called "Promoted to front page" which most people misunderstand, or don't use. I, on the other hand, have been using this this 'flag' as a lightweight version of flag module for some time.
If most people don't understand or use this much, shouldn't we remove it as its UI clutter?
Wordpress has no flag feature. On a fresh install, the homepage displays posts by recency, not needing a flag (not that they're the end all be all but they do cater to normal users). Removing it simplifies the UI
I think "Promoted" will confuse new users as well, especially with no context provided.
"Published"? Check.
"Sticky at top of lists." Uncheck.
"Promoted"? Huh? Promoted to what? Promoted to the top? A sticky?"
You use that flag feature everywhere but you're an advanced user. I could be wrong but I suspect the built-in flag feature isn't heavily used in Drupal nor in Backdrop, except for a few advanced users. Maybe others would like to chime in on this if they actively use it? (not the contrib modules)
It won't harm anyone but it will confuse new users (like me back then) I am also suggesting we remove the built-in flag primarily as a UX issue.
In #1260, you suggest removing syslog... a core module found in Drupal 7 because
it was primarily a UX issue. People will turn it on to see what it does. But enabling the module won't do anything because you need server configuration chops in order to actually "turn it on".
I could say something similar for syslog
Other core modules were removed like Forum and you now need to use a contrib for that so it's not the first time. The reason I vote for both syslog and the built-in flag feature is it's not something normal users would use or easily understand. It's more for advanced users.
I guess I just don't see how it needs to be in core apart from,
Yeah, Drupal always had it and I, an advance user, use it heavily.
At the very least, I think it shouldn't be shown to new users.
I'm interested in what others think... maybe it's just me and it just might be.
[edit] to summarize, exposing this over complicates the UI (clutter) and adds something for writers to unnecessarily think about. Moreso since this feature appears in the create/edit node page, which most users are exposed to constantly. I still don't see the use cases where a normal user would want to use this built-in feature. To me, I've noticed there's a difference when I try to write a new post in Wordpress compared to Drupal/Backdrop. I'm not sure what yet but I wonder if it's the extra options. For now, I'll back away from this issue and let others chime in. Maybe it's not important or maybe I'm missing something obvious.
klonos
commented
8 years ago Fair enough for all of these, but my point is to have it so that instead of having another Drupal/Backdrop "special thing", we convert this setting to a proper boolean field that:
dboulet
commented
8 years ago One thing that I feel needs to be brought up in this discussion of promoted content vs. flags vs. fields is that of performance. The reason the the “promoted” property is favoured over the others is that it simply correlates to a column in the “node” table in the database. This means that you can query the database for promoted content, and it will be very efficient because it only needs to consult a single table without needing to use joins. This is the same reason that node titles are not stored in fields: so that lists of nodes can be generated very efficiently.
The “promoted” property is really just a way for users to indicate that certain content is “special”. You can then choose to display these on your site, in any way you want, by creating views which filter for promoted content. Sometimes that means showing them on the front page, but they can be displayed anywhere.
That being said, I like @jenlampton’s original idea of simply changing the label to “Promoted”.
sutibun
commented
8 years ago The “promoted” property is really just a way for users to indicate that certain content is “special”.
Wow, you expressed that nicely... even I understood right away. In fact, you gave me an idea that might help solve everything. (I hope)
At first, my mind immediately thought of the word "Favorite" as opposed to "Promoted". Then, it thought of the Facebook Like button. And finally on the GMail inbox star button.
How about instead of relying on words, we use a star? "Star it." Since you want to make the flag name ambiguous (flag... a word that I had a hard time wrapping my head around), let's use something that is ambiguous but still familiar and user friendly
On the node edit form, you can place a star "button" next to the title post.
If you think this content piece is "special" in some way, you star it. This I think is something users can much more easily understand (like me!)
And it'll be even easier to grasp when you see a listing of posts. Similar to GMail.
In this way, the flag can remain without confusing new users. If Drupal had a star, my experience would've been much better. What do you think?
hehe sorry but monkey thinks simple.
docwilmot
commented
8 years ago That being said, I like @jenlampton’s original idea of simply changing the label to “Promoted”.
I'd go with that. With an entry in docs somewhere to explain.
klonos
commented
8 years ago UX-wise, I think that the Monkey is right in that end-users would grasp more easily the purpose of the "special" or "promoted" if it was simply called "favorite" and we had a star instead of a checkbox. Not a fan of the idea because my goal is to have this feature NOT be another Drupal/Backdrop-ism in the back-end, but still @sutibun has a point.
I do not particularly care if this is a flag or a tag (vocabulary term) or a field. I just want to generalize/abstract this so that it is extensible (by other modules) and easily configurable through the UI. Simply renaming the thing would mean to change an already "hard-coded" label to something different and would still require people to "hack core" in order to change it or remove it. That's my 2c.
BTW...
This is the same reason that node titles are not stored in fields: so that lists of nodes can be generated very efficiently.
I kinda understand that (Nate has already explained a few more reasons as to why node titles are not fields over in #933). But from my experience in d.org every time we special-case something, it eventually returns to bite us (views pagers and their "lite" version that would not show the total number of pages is an example that comes to mind).
I'm guessing that these decisions to special-case the node title and the "promoted to front page" property were made some time ago because they've been around for some Drupal versions now. Do we have any rough idea of the performance hit with current hardware - especially shared hosting that is our target audience?
docwilmot
commented
8 years ago I have a suspicion we're confusing this issue here.
The promoted checkbox exists on the node/add page simply to toggle one little value on the $node object: $node->promote. Thats because previously nodes with a value of 1 for that key ended up automatically on the front page, while 0's did not. That rarely is useful anymore because nobody uses a front page view anymore. So that checkbox now does nothing.
So this issue is just to decide if the checkbox should say 'promoted to front page', or just 'promote', or something else, because saying 'promoted to front page' might confuse persons who dont even have a front page view, that toggling it may somehow cause the node to appear on their front page. In the end whatever it is, a checkbox, radio, star, lightning bolt, whatever, all it does is toggle that one (now very nearly useless) value.
Personally I feel that for an admin to write an article, for example, and then 'favorite' it himself doesn't really make much sense. Especially if favoriting it then has no other visible effect whatsoever.
So I'd say just change it to promote, and explain that it just marks the node, but does nothing particular unless you want it to (for example it will be included in the Front Page View if you decide to use that View, or you can use it to filter other views, whatever.)
sutibun
commented
8 years ago I'm going based on what Jen said:
All I was proposing was that we change it's name. If we called it "Promoted" then people could use it for whatever they wanted. We could keep the existing behavior of having this box control what's on the home page (backwards compatability++) but also turn it into a useful tool for other things.
I think I finally understand her.
What I got from her is that the name change is to make the flag feature more accessible and broad. i.e. it can have multiple purposes. By renaming it to "Promote", it's no longer mysterious and confined to one purpose and so users can consider using this.
What I am saying is, if we're trying to make the flag feature so it's general purpose, (I've come around to not removing the built-in flag feature) it would be much better and more user friendlier to NOT use words at all. (no "promote", no "favorite", etc)
"Promote" is no doubt an improvement to "Promoted to front page" but a star image/icon is even better.
So I'd say just change it to promote, and explain that it just marks the node, but does nothing particular unless you want it to
A star button/icon/image, I believe, achieves all that without needing to explain to the user explicitly.
When I first heard of "promote" or "flag", I was totally unclear what you guys were talking about. However, when I made the connection that it's similar to a GMail star, that's when I realized that I've been using flags everywhere. I just got it.
It's used everywhere.
This is why I think a star is more suitable.
PS: My main concern is providing a UI element that is much more widely understood and doesn't trip users. You guys can fight over the backend :p I'm not suited for those kind of conversations.
docwilmot
commented
8 years ago When a user sees a star in a listing
Unfortunately, this issue is not about the listing of nodes, its about the node edit/add page. Once you've marked the node as promoted, then yes, you can put stars next to the "promoted" ones, but thats a different issue.
And I don't think it is reasonable the creator of a node to have to star it himself. You don't "like" your own posts on FB, or star your own emails in GMail while youre typing them.
mikemccaffrey
commented
8 years ago +1 for @jenlampton's simple proposal to rename "Promoted to front page" to "Promoted". Larger architecture discussions aside, does anyone have an objection to that change?
However, there is one small issue that needs to be addressed: the default front page view starts off saying "No front page content has been created yet." We would need to change that empty text to say "No promoted content", or there'd be no way for users to figure out how to get content onto that front page.
klonos
commented
8 years ago ...does anyone have an objection to that change?
Generally speaking, I don't think that anyone objects. That is with the fact that "Promoted to front page" doesn't make sense any more if the default front page view is replaced in a setup (guessing that that's the case in most installations). It's just that if we are to rename it, it better be to something that creates less confusion. Simply calling it "Promoted" might seem ok for all us old-time Drupal users, but I am positively sure that newcomers will wonder "Promoted?? ...where? ...what does this thing do?".
So the reason why we are bike-shading here is to figure how to rename this to something that will be meaningful for all ...or make it so that site builders are either able to easily rename it to whatever makes sense for their site/users/target audience or remove it altogether and have it so that people can use a generic, non-drupalismistic solution (like the word I just came up with?).
sutibun
commented
8 years ago Once you've marked the node as promoted, then yes, you can put stars next to the "promoted" ones, but thats a different issue.
And I don't think it is reasonable the creator of a node to have to star it himself. You don't "like" your own posts on FB, or star your own emails in GMail while youre typing them.
Maybe it's me but not sure I get it. Currently on the actual Bd edit/add page, you have a UI element to flag a post. A checkbox called "Promoted to front page" (possibly to be renamed "promoted"). So creators can currently promote/"like"/mark their own posts, even while creating it.
Except with the star, it wouldn't be any different. You'd simply mark your own post with a star button instead.
Simply calling it "Promoted" might seem ok for all us old-time Drupal users, but I am positively sure that newcomers will wonder "Promoted?? ...where? ...what does this thing do?".
Bingo.
PS: Even GitHub implements stars for flagging. They use both the star image and text label "star". Basically eeing more stars lately.
mikemccaffrey
commented
8 years ago @sutibun: The feature you are describing is certainly useful and widely implemented on many sites, but it is fundamentally different than how the "promoted" field has been traditionally used in Drupal. The promoted checkbox is intended for manual curation of featured content by site editors (think of the Editor's Choice carousel you see when you open iTunes), while a star flag is intended for positive feedback/bookmarking by general users.
We can certainly consider adding some sort of starring/favoriting to core if it is something that would benefit the majority of sites using Backdrop, but it would need to be a separate discussion. The promoted/sticky checkboxes simply contain some value for each node, while implementing starring/favoriting would requiring tracking the relationship between a node and all of the users who have starred it, requiring a more complicated process and managing a separate database table.
sutibun
commented
8 years ago The feature you are describing is certainly useful and widely implemented on many sites, but it is fundamentally different than how the "promoted" field has been traditionally used in Drupal.
Checking the "Promoted" checkbox vs clicking a Star button is no different other than cosmetics. They both flag a node. When you click either one, you mark the node.
The promoted checkbox is intended for manual curation of featured content by site editors (think of the Editor's Choice carousel you see when you open iTunes), while a star flag is intended for positive feedback/bookmarking by general users.
To manually curate featured content using the "Promoted" checkbox, you'd create a View filtering nodes that have "Promoted" toggled. It'd be the same with the Star flag. Create a View filtering nodes with the Star toggled and you'd get the same editor's carousel.
The promoted/sticky checkboxes simply contain some value for each node, while implementing starring/favoriting would requiring tracking the relationship between a node and all of the users who have starred it, requiring a more complicated process and managing a separate database table.
I am not suggesting a favoriting feature that would require tracking relationships (actually, not sure what you're referring to). What I am suggesting is sticking with the current implementation of the built-in flagging feature. The only difference being on the front end more or less. Instead of a checkbox that says "Promoted", you'd have a Star button that you'd click to toggle the flag. The doc explained it earlier, assuming I understand it correctly:
The promoted checkbox exists on the node/add page simply to toggle one little value on the $node object: $node->promote . Thats because previously nodes with a value of 1 for that key ended up automatically on the front page, while 0's did not.
The Star button would use the same mechanism. Toggling the star button would toggle the value on the $node object. $node->promote When the star is "off", the value = 0. When the star is "on", the value = 1. I don't see where the complicated process comes in.
The Star flag implementation is no different from the "promote" flag implementation on the backend. The only difference lies on the front end, in how you toggle the value, BUT it's a massive difference.
Which conversation would be much easier.
Normal user: How can I handpick certain posts to be featured on my blog in the carousel?
Drupal user: Go to each post, check the "promoted" checkbox, and create a View and filter posts by those that have "promoted" set to yes.
Normal user: in his head Promoted? Checkbox? uhhh ok. This seems hard. Maybe I should look for a dev to do this for me or just go to Wordpress.
vs
Normal user: How can I handpick certain posts to be featured on my blog in the carousel?
Bd user: Star each post you want featured and then create a View that filters by starred posts.
Normal user: in his head Oh, like the stars on Twitter, GMail, GitHub, etc. Makes sense. Thanks!
A normal user would much better conceptually understand stars. This is helped by the fact that stars are used elsewhere, and thus people can build off their past experience.
Like I said earlier, given that stars are symbols, a user can impart any meaning they want to it.
Twitter Favorites were first used solely to bookmark Tweets you wanted to read later...
But these days, Favorites are used similar to the "like" button on Facebook...
We now star/Favorite Tweets to express, hey, I like what you're saying here, or to answer a yes/no question in the affirmative. Sometimes after a lengthy @ reply chain, i.e. two or more back-and-forths, users will Favorite the final tweet to acknowledge receipt and put an end to the prattle.
Twitter star has changed meaning.
Starring a repository allows you to keep track of projects that you find interesting, even if you aren't associated with the project... You can see all the repositories that you have starred by going to your stars page
This goes back to Jen's idea of
If we called it "Promoted" then people could use it for whatever they wanted... also turn it into a useful tool for other things.
The star symbol is versatile... and thus can turn "into a useful tool for other things." while also being user friendlier.
Anyway, I tried my best. Think said everything so don't have much more to contribute so I'll bow out. I leave it to the judges.
docwilmot
commented
8 years ago @sutibun for what its worth, this last essay has me nearly convinced. :smile: Only reservations:
But you have me convinced this could make a contrib module, if the module also produces a visible result from the toggling. The "Star Promote" module perhaps?
sutibun
commented
8 years ago ^_^ And I normally procrastinate when I have to write long posts elsewhere.
I just get super passionate when it comes to improving the UI + UX, maybe I go a lil' overboard. (a reason sometimes I have to step away) Especially when it means a new Bd user won't experience the Drupal mess & confusion I went through. I don't need expensive "official UX research studies" to realize where most problems are. Maybe it's my past exp but they're fairly obvious to me.
Developing the latest whizbang CMS feature and matching Drupal may attract the curious onlookers to Bd, but the UX and ease of use is what will help keep them here because at the end of the day, the user has to use the CMS every day.
Drupal has tons of nifty features but it might as well not exist if users don't understand what it is or how to use it. It's like unrealized potential. Wordpress may not have as many Drupal features, but the feature they do have, they polish it so it's used AND appreciated. i.e. it doesn't go to waste
Only now, after a long discussion here, do I see the power of the built-in flags and how I could take advantage of it. That's latent power.
...that this be would still (or more) confusing for the user: a star toggle that does... absolutely nothing
True, they'll toggle and maybe not understand it...
...on the first try.
Fortunately this isn't a vacuum. The user will take a mental note of the star. When they next go to the "content admin" page ("/admin/content/node") and see a column of stars (with maybe a few post they might have starred in the past by accident) things will get much clearer.
Like so:
1 + 1 = 2
There never were explicit instructions on GMail on what the star did but people picked it up nonetheless.
Of course, I have my own suggestion on where to put the star exactly on the edit/create page so it's in your face but in a weird way subtle.
At worst, a user will click the star button and move on when they can't figure it out on the first try. Because it's a "star", they'll think nothing of it and won't cause friction.
Yet, with a star, there's a way higher chance of users stumbling and learning to use the flagging feature on their own compared to the checkbox.
At first, a user might use the star to "favorite" posts internally to see on the admin content page. But when they go to Views and see something like "filter by starred posts", they'll begin to think bigger.
...it means introducing a unique element - with the code maintenance issues that brings - for only a very small result.
Well, I don't know if it's a very small result. To a user, it'll be like you just introduced a brand new feature (when all you really did was expose it to more people)
Whether this is urgent or a priority, well, that's not for me to decide since I won't really implement this. This though would fit nicely in the 1.3 UX release.
docwilmot
commented
8 years ago Compromise: for 1.3.0, which is coming up rapidly (its right after Christmas, note), can we do "promoted" and leave this issue to decide on a new UI and system for listing promoted nodes?
We need to start doing PRs.
sutibun
commented
8 years ago Sure, though I should be the one doing the asking/asking for permission.
I'm just giving ideas & the vision, not the one who will actually implement. The developers get to decide whatever they want to implement.
But if you're really asking me, I always say go with the most practical in the short term. No one is going to die if this isn't implemented right away.
Plus, you have a better understanding of what other stuff needs to get done, your time, inclination, is this the highest priority, etc
jenlampton
commented
8 years ago I think we're ready for a PR, no?
klonos
commented
8 years ago I just did a quick search for the use of the word "featured" in this page and it gave 6 matches (will be 7 now with me mentioning it). It has been used to describe what we mean by "promoted" but never actually suggested as an alternative. Don't mean to derail/prolong the discussion, but I think it makes better sense.
https://www.google.com/search?q=define+featured
have as a prominent attribute or aspect. ... have as an important actor or participant. ...be a significant characteristic of or take an important part in.
sutibun
commented
8 years ago always the contrarian :p
jenlampton
commented
8 years ago I also prefer Featured. It will work better for people outside of Drupal/Backdrop too.
Unfortunately Changing the language to Featured is a little harder because ideally we'd like the code (and database schema) to match the user interface, but that would be an API change. $node->promoted will need to become $node->featured.
Let's start here and do a follow up for backdrop 2.x for the featured change.
quicksketch
commented
8 years ago The PR looks good to me.
From the PR, pulling the discussion back over here so it's in one place. @docwilmot posted:
I think this needs description text on the checkbox explaining that it does nothing unless you want it to. "Marks this post as 'special'; this will allow you to filter these posts in lists if needed, but otherwise doesn't affect the display of your posts.". Or like that.
I think it makes sense that this sort of site-building advice would be shown on the content type form, but not on the node form itself. In many sites, the site-builder and the editor are not the same person, so the user that sees this description text may not actually have any ability to affect how the promoted content is actually displayed. For site-builders, we already provide some similar text when configuring a type:
But for the content itself, I think we should leave it undescribed because we don't know what purpose the site-builder will use the "Promoted" property.
docwilmot
commented
8 years ago Youre right.
quicksketch
commented
8 years ago Ha, okay thanks @docwilmot! This was quite a winding path to such a simple change. Thanks everyone for your feedback here.
https://github.com/backdrop/backdrop/issues/1155 has been merged into 1.x, so it will be in 1.3.0.
The name "Promoted to front page" really only means "shows up in the default Front page view". Most sites don't even end up using this view.
I would love to see this checkbox to be simply "Promoted" so that each site could choose to make use of this flag however they need. By default, let's leave it the same. But if we remove "home page" from it's description or explanation it will be a more flexible tool any site can use for any purpose.