[US - DEV] As MILES HARDIN, I want to see my idea’s status in a tag so that I can know where my idea is in the process to be approved by Dev Launchers

[JulieMass]

Considerations:

We need to include a tag for each idea in the dashboard page so Miles can know their respective statuses. For example: is an idea in workshopping, development, archived, closed, etc. phase? If it is in the "workshopping phase" then the label should show "workshopping" and so on.

Note:

• Tags component can be reused from the library created from the Platform enablement team (#683)
• Please refer to the dashboard page UX designs in Figma

Relevant documentation:

• "Archived" and idea was developed in item #839
• "Delete" an idea was developed in item #838
• "Submit an idea to be reviewed" by Dev Launchers is being currently designed with item #1424
• Information about our Ideas roadmap and flow can be discoved in our FAQ content document.

Acceptance criteria:

• Ideas have a status tag in the dashboard page.
• Idea’s statuses should update accordingly. For example: if an idea changed from “workshopping” to “approved”, its tag should show the last one.
• Ideas Status change in the following flow:
  1. "Worshopping" tag: Applied after Miles submitted his project idea through the idea submission form
  2. "Archived": Miles, as the idea owner, can opt to archive an idea that is being workshopped. After the idea has been submitted to Dev Launcher or approved, it cannot be archived.
  3. "In review" (or old "Applying") tag: Applied after Miles sends his idea to be reviewed by Dev Launchers (functionality not yet developed).
  4. "Approved" tag: Applied when an idea project was approved by Dev Launchers and became a project (functionality not yet developed)
• Tags follow the new design system styleguide tag component styles.
• The idea’s statuses tags are web responsive and adapts for mobile, tablets and desktop breakpoints.
• Features were tested thoroughly and works seamlessly on all devices and target browsers : Chrome, Microsoft Edge, Safari, Firefox and Opera.

---

Sub-tasks:

• [x] UX design #780→ We’ll work on this task pairing UX design with development: Anwar will work on designing the UX design mockups in collaboration together with Iris developing this task.
• [ ] Development

• [ ] QA

Idea's status roadmap / flow:

IdeaSpace tag labels (with outdated color styles) and tags with updated colors from the New Universal design system styleguide:

[JulieMass]

(CC. @dbradham)

@alicefate I created a user story for you to develop the idea statuses tags. We'll discuss definitions in more detail in today's meeting with Anwar. Please, after the meeting, can you estimate it 🙏?

[JulieMass]

Hey team! Please add your planning poker estimate with Zenhub @dbradham @alicefate @JulieMass @Nouri-Anouar

[JulieMass]

Hi @alicefate, I've included above in the ticket description, @Nouri-Anouar's designs for each status tag state, so you know the colors he defined for each one.

[JulieMass]

@dbradham is there a way the QA team can access the dashboad currently in staging? I'm asking so we can assign this ticket to them for their review.

[JulieMass]

(CC. @dbradham)

I'm gonna move this ticket to "blocked" because, unfortunately, I couldn't test it due to the author's issue 😔.

[JulieMass]

(CC. @dbradham)

I'm gonna move this ticket to "blocked" because, unfortunately, I couldn't test it due to the author's issue 😔.

Hey @dbradham I noticed that the reason this ticket was in the blocked column was actually because of an issue with the author. This wasn't letting us see the ideas in the dashboard. Also, staging is broken right now, so I wasn't able to double-check anything.

Anyway, do you still think Hindu could work on this ticket and update the labels like we discussed today? Or would the author issue prevent her from doing that?

Let me know what you think!

[JulieMass]

Hey there @Hindu-Priya !

So, after discussing with @dbradham, and since this ticket has been around for a while under the blocked column, I went ahead and updated the acceptance criteria and added some new pictures. We just want to make sure the tag styles are in line with the new design system guidelines.

Also, for the second tag, I'm thinking we should change it from "Applying" to "In Review". The reason is that this tag is connected to the task Noa is working on, which is about “submitting an idea for review”. @NokaUX , let us know please what you think about this.

Hindu, I'm assigning this ticket to you, adding it to our current sprint (please update the ticket status once you start working on it) and let me know if you have any other questions!

Thank you

[Hindu-Priya]

Hey @JulieMass ,

Thanks for the update, @dbradham and @JulieMass. I've noted the changes to the acceptance criteria and the tag adjustment. @NokaUX, your thoughts on the tag change would be valuable. I'll get started on this ticket right away and update the status accordingly. Thanks!

[JulieMass]

Hey @JulieMass ,

Thanks for the update, @dbradham and @JulieMass. I've noted the changes to the acceptance criteria and the tag adjustment. @NokaUX, your thoughts on the tag change would be valuable. I'll get started on this ticket right away and update the status accordingly. Thanks!

Thank you Hindu! feel free also to update the final estimate if you need to.

[Hindu-Priya]

Sure Julie, will do it.

[dbradham]

@JulieMass my "deleted" idea is showing up here as "workshopping".

What is the expected behavior here?

[ghost]

Hey @JulieMass and @Hindu-Priya ! I like the idea of changing the tags' name from "applying" to "in review", and agree with you on it, It does make more sense! Updating the Figma file accordingly, and attaching the updated diagram to this thread

[JulieMass]

@JulieMass my "deleted" idea is showing up here as "workshopping".

What is the expected behavior here?

Hi @dbradham ,

• The expected behavior for a DELETED idea is described in the following #838.
• The behavior expected for an ARCHIVED idea is described in item #839

For further information about how the flow for an idea works in IdeaSpace, the information is in our FAQ content document we created with Marilia.

I hope this helps clarifying,

(CC. @Hindu-Priya, @NokaUX )

[JulieMass]

Hey @JulieMass and @Hindu-Priya ! I like the idea of changing the tags' name from "applying" to "in review", and agree with you on it, It does make more sense! Updating the Figma file accordingly, and attaching the updated diagram to this thread

Hey @JulieMass and @Hindu-Priya ! I like the idea of changing the tags' name from "applying" to "in review", and agree with you on it, It does make more sense! Updating the Figma file accordingly, and attaching the updated diagram to this thread

Thank you @NokaUX for your feedback! @Hindu-Priya , let's move forward with the "in review" tag.

However, Noa, there seems to be some confusion, as there is no "review" step between an idea being submitted and it moving to the workshopping stage. The idea flow is described in a picture in this item’s description and I also mentioned this in the flow that you shared in our Discord Channel. Ideas move from “submitted” → “Workshopping” → “in review” (this is the task you are currently designing Noa in your ticket #1424) and finally an idea gets “approved” by Dev Launchers.

Here is a graphic that should help everyone to understand the ideas flow and also the tags that should be assigned correspondingly. This information is in our FigJam here:https://www.figma.com/file/uI7sKOvgtHhQYROxGgX2wq/%5BDL---IdeaSpace%5D-Story-mapping?type=whiteboard&node-id=0%3A1&t=shhTRWis2A23dPWj-1

@Hindu-Priya I'm updating this iteem description with this info as well so everything is updated.

[Hindu-Priya]

Hello @Enjoy2Live, @dbradham, and @JulieMass! As recommended, I tried to use Tailwind CSS to style the tag and can't seem to access Tailwind. Perhaps something is missing, for not being able to apply Tailwind CSS classes correctly.

[Enjoy2Live]

Hello @Enjoy2Live, @dbradham, and @JulieMass! As recommended, I tried to use Tailwind CSS to style the tag and can't seem to access Tailwind. Perhaps something is missing, for not being able to apply Tailwind CSS classes correctly.

Hi @Hindu-Priya , did you run yarn workspace @devlaunchers/tailwind dev? this command is responsible for watching the changes you make on the code and generate the classes you write to a css file found in packages/tailwind-constructor/tailwind.css so the command is always running and watching changes and shouldn't be terminated.

if you've already done this and your styles still don't apply can you please tell me which branch you're working on currently so I can investigate it further?

[dbradham]

@Hindu-Priya I am not seeing the expected results in staging after deploying here-

[Hindu-Priya]

Hello @dbradham,

Before merging into the master, it worked fine. After merging, it is behaving unexpectedly. @Enjoy2Live, I would appreciate your thoughts on it.

[Enjoy2Live]

@Hindu-Priya can you describe how it is behaving unexpectedly? steps to reproduce would help me figure out what went wrong.

[Hindu-Priya]

Hello @Enjoy2Live,

I'm not sure what went wrong, but it seems like Tailwind CSS isn't being applied to the tag.

[Enjoy2Live]

@Hindu-Priya I need steps to reproduce or the branch where you're having the issue otherwise I'm afraid I can't assist.

[dbradham]

@Enjoy2Live this change has been merged to branch master

Please see below for an example of the issue. The class name appears to have been rendered correctly, but no styles are applied to the element.

[chadcrotchett]

BLOCKED: Chad coordinate with Mohammed

[Enjoy2Live]

@dbradham I see why, the className got changed from bg-Orange-orange-100 to bg-orange-100 because design team always decides on which format seems better fit, one way to find out before things get to staging or prod is by using our eslint config that I did a demo on some time ago.

It has a entry called "tailwind" and it does many helpful things like checking if the class you have applied exist in our tailwind config, orders classes so it can be easily read etc.

steps are easy tho no one seemed interested but now I hope this sparks some interest!

Here's the epic I made for each team to complete in order to have linting running https://app.zenhub.com/workspaces/platform-enablement-63529f02029ee50018fe58c6/epics/Z2lkOi8vcmFwdG9yL1plbmh1YkVwaWMvMTczNTg4 Link to the forgotten demo and announcement message I made https://discord.com/channels/829463953087660083/845028512841596978/1197991160476606484

Feel free to reopen the issue within this epic (I closed it out of frustration as no one really worked on it)

[dbradham]

@Enjoy2Live thanks for getting to the bottom of this!

One follow up here from my side, why is the design team changing the format/names of the classes for styling? Shouldn't that be static?

When Hindu was testing locally, this worked. But by the team she deployed to staging, it was broken by that change. That seems like the same issue would have happened here even if she were using the eslint tools, because the class name was valid at the time she implemented it.

My suggestion would be for the design team to update existing references to the tailwind classes when they change them, or avoid changing them altogether. Otherwise I believe we would repeat this problem in the future.

[Enjoy2Live]

@dbradham

why is the design team changing the format/names of the classes for styling? Shouldn't that be static?

A design system is something that evolves alot especially during its infancy and I understand your point of view because we're both developers but we want tokens to refer to a specific context so developers/designers know on top of their mind where to use a specific token and reduce the decision making when new features are in the making while supporting theming for the org in the future, the below img should give you an idea of how tokens can reduce decision making by applying subset of primitive colors [color-white] to predefined semantic tokens [bg-default] implying the default bg color should be white

Design tokens explained (and how to build a design token system) We're in the point of refining the way primitive tokens are named and soon enough we'll jump to write semantic tokens that would require us all to change tokens in each app from primitive tokens to semantic tokens.

At some point the changes will be minor and these types of errors shouldn't occur, we're not there yet so it's advised to use eslint now with CI in place while rebasing from master periodically to avoid these type of errors.

When Hindu was testing locally, this worked. But by the team she deployed to staging, it was broken by that change. That seems like the same issue would have happened here even if she were using the eslint tools, because the class name was valid at the time she implemented it.

We have thought of this and every time design team makes a PR that changes the tokens (found here btw) a CI job starts telling them what apps got their styling broken after the change, only apps that enabled our global eslint config though (so far no one uses it except @devlaunchers/components or global UI components lib). enable eslint config so I can get reports and every time a reference is broken I'll be sure to fix that on the spot before things even get to master.

Thanks for understanding!

[dbradham]

Thanks @Enjoy2Live for the explanation here. That is helpful to know why these changes are happening.

Just to recap-

• If we implement eslint, then you will fix issues like these moving forward
• If we do not implement eslint, then we need to debug the issues ourselves like in this case

Let me know if I am misunderstanding that, but it sounds like good incentive to implement eslint to me!

[Enjoy2Live]

@dbradham you got it right, telling other team leads about the issue you had might incentivize them to implement eslint.