Open CameronMcWilliam opened 4 years ago
@ddunn2 @KyeMaloy97 @Bazif-Khan Would like to get your thoughts on how we might be able to best show this on the stacks page.
Assigning to Kye to work with David and Bazif and put a design proposal/screenshot of ideas into this issue.
Here is a first pass at the design me and Neeraj have spoken about, open for opinions, improvements or alternatives. The text shows when a user hovers over the image, however there is no hover state on mobile phones, but do we think people are going to be needing that level of detail on the go?
The sidebar is also up for debate with regards to having a key in it for the icon.
Thanks @KyeMaloy97 !
My first thoughts on the proposed design:
I like the use of an icon for indicating this stack is different from others.
I also like having a key to explain what the icon is for, but dont think hte current design gels with the checkbox lists in other sections. It seems a little out of place.
Lastly, not sure what is the equivalent for hover text on a mobile view.
@neeraj-laad we've just discussed this and Kye is going to try making the icon orange so it stands out a bit more.
Bazif thinks we can use "on click" for the hover text on mobile.
We've also agreed to remove the key and see how it looks, as you're right the key doesn't fit with the checkbox lists in the other sections.
So look out for an updated screenshot...
I have made the icon orange, one option for showing the message on mobile could that clicking the triangle shows an alert. This is how it would look on iOS:
And here is the page on desktop with the orange icon:
Have also added some logic so the alert doesn't show on Desktop, only on mobile. On desktop hovering works as it did before.
This looks good enough to me.
@neeraj-laad @helenmasters
Another point relevant to this discussion is the fact that java-microprofile features prominently in the "Most Popular" four stacks on the https://appsody.dev/ homepage.
If that's calculated dynamically from downloads I realize it's non-trivial to change, but... would be nice to not be pointing to this when we'd rather promote java-openliberty to any user.
Anything else we could do here? Separate issue? Thanks
+1 for deprecated stacks to drop off the "Most Popular" list on the front page and for the replacement stack to take its place.
It would be simple to remove the deprecated stack from that element, using something like a filter on the list that is retrieved from docker hub (how we get the pull counts at the moment) but I am not sure how complex it would be to replace the deprecated stack with the replacement stack as it would require working out what stack replaces the deprecated one, AFAIK that might not even always be the case (in cases where a stack is simply deprecated and theres no replacement).
Also, the text that goes in the deprecated field has no forced structure so working out if it contained a replacement stack, and working out what that stack is would be an issue in itself haha
+1 for deprecated stacks to drop off the "Most Popular" list on the front page and for the replacement stack to take its place.
Most popular means most popular and I would hope that OL would naturally replace MP over time. As Kye says, we can filter deprecated stacks out, but I don't think we should be trying to replace them. That's is a whole different discussion where we would now be deciding what we want to showcase.
Having deprecated stacks removed from the "Most Popular" list is a start.
Can/will we redirect users from java-microprofile to java-openliberty too somehow? This will be helpful to ensure that users pick up the replacement stack.
There is no mechanism in place for that at the moment as AFAIK, the stacks deprecation field i just a message and a date, so theres no defined place where a URL or stack name goes to define a replacement
Can/will we redirect users from java-microprofile to java-openliberty too somehow? This will be helpful to ensure that users pick up the replacement stack.
@yeekangc - not sure I understand what you are suggesting here. Please can you open a new issue for this and provide more of an explanation as to what you would like to see happen. At a minimum the MP stack README should have a clear message to use OL instead, which should be down to the stack owner.
For what we are designing here in this issue, besides marking a card (stack) as deprecated, can we at least provide an indication of the strategic replacement/alternative i.e. the next step?
Cc @awisniew90.
Agreed - perhaps in the warning message, instead of saying "Please use an alternative stack" we could suggest which stack to use or provide a link to it.
^^ @CameronMcWilliam @neeraj-laad - please see comments for implementation considerations. Kye can pull whatever data you put in. If there is a strongly adhered to format for specifying a replacement stack, he can probably code to pull that out. Otherwise he can just print whatever is in there ... and stack owners can decide what they want to say.
This is just a prototype. The warning message will actually be the message you put in stack.yaml and should contain the reason for deprecation and the recommended alternative.
This will be the same warning that CLI will show users' while working with a deprecated stack.
The website should not have to do any transformation. It should just spit out the deprecation message from the index.
@KyeMaloy97 I know we're facing some gatsby issues with merging this PR, so wanted to know if there is a simpler design we could go with as a first pass to get this in?
@neeraj-laad So our options are what we discussed before this PR was opened, with having one stack at all times having a deprecated field on it because Gatsby pre v2.9 does not allow you to have a field referenced in the query that doesn't exist on any of the items its looking through, there is an API for it in post 2.9 but we can't use it.
So we either have to make sure there is always a deprecated stack, not the end of the world for now as you are about to deprecate one but for the future it may cause issues if you want to remove a stack from the website, leaving no deprecated ones. As soon as the updated YAML is built into the website, probably the following morning, the site will fail to build.
Another option is having the sample stack display on the site, with a deprecated field at all times but hide the stack so it never shows to an end user. That means it wont matter if any of the normal stacks lack deprecated fields as the sample one will always have the field available to satisfy the query.
The latter option will take longer as it is something new that hasn't been done yet whereas the first option should be faster as I had that working originally.
Is your feature request related to a problem? Please describe. Display deprecated stacks clearly on website.
Describe the solution you'd like Could replace the stack description with the deprecated message.
Additional context Related to PR #923