[FOLIO-1268] Mockup labels are inconsistent with existing labels Created: 04/Jun/18 Updated: 18/Jan/19 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | md331 (Inactive) | Assignee: | Cate Boerema (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: | |
| Development Team: | Core: Platform |
| Description |
|
Other developers and I have recently noticed that the labels used on mockups sometimes doesn't match what already exists in code. This leads to uncertainty about whether we should implement the mockup or maintain consistency in FOLIO. An example is "Save and close" labels. The new Service Points and Staff Slips code added new "Save & close" translation strings,
It would be helpful if we standardise on some particular wording for development's and i18n's sake. If the desired wording changes in the future, a JIRA should be made to bring all the existing labels into line. There's no real action items or anything for this, but I brought this up in today's (June 4 2018) meeting and Jakub suggested I file this so the POs can be made aware. |
| Comments |
| Comment by Cate Boerema (Inactive) [ 04/Jun/18 ] |
|
Thanks so much for raising this, md331! I think the "Save and close" language was created when we decided to implement buttons which allowed the selection of different kinds of saving (e.g. save and close vs save and keep working). But we haven't implemented that feature so maybe we shouldn't change the label until we do. Looping in Filip Jakobsen for his thoughts |
| Comment by Filip Jakobsen [ 04/Jun/18 ] |
|
Thanks for bringing this up, md331, and for looping me in, Cate Boerema! From my point of view, the best way to approach solving this problem, is to implement mockups as they are, for new features, and raise concerns to the UX designer in question if you can see that there are similar, but slightly different wording, design, etc. in other apps. And if you see a mockup for an existing feature that has a different wording, it can be ignored unless it is also explicitly stated in the user story for that feature that the label should be changed. We have an ongoing dialogue amongst the UX designers about how we should phrase things, and I think it might be most meaningful to create separate tasks of e.g. going through all apps and putting in the right translation string on the appropriate buttons. We recently made a page on the UX documentation site that will grow and develop as we make rules for more of these things. It currently mentions the text in question here, in the "Ampersand" section: http://ux.folio.org/docs/design-guidelines/style/language-rules/ Let me know if you have any other questions, or if I misunderstood the question asked – thanks! |
| Comment by Cate Boerema (Inactive) [ 04/Jun/18 ] |
|
Thanks, Filip Jakobsen! I just want to make sure I understand. You are saying the developers should code to the mockups (I like this - it's very clear). Design patterns are changing so we know that coding to mockups will result in some inconsistencies across the product. We will address the inconsistencies through an explicit (periodic?) cleanup effort driven by the UX team. I like this approach, especially if the UX team was writing up the stories/tasks for addressing the inconsistencies. All that said, I do think there may need to be some discussion among the UX designers about when it makes sense to start using new patterns in mockups. For example, suppose we thought the Save and close nomenclature only made sense for the button with multiple save modes. I would then think we should not use that label in our mockups until we are ready to implement the button that has multiple save modes. Thoughts? |
| Comment by Filip Jakobsen [ 04/Jun/18 ] |
|
Cate Boerema, in general, your summary captures what I was trying to say. "Save & close" is what all the edit modals will do, even if there aren't any alternatives to the "Save & close" options, so I think this pattern is ready to be implemented. I think it has value that it is explicit, even if there are no alternatives yet. Getting to the underlying problem your question focuses on, we should figure out ways to communicate things more clearly when a new pattern is made "official". Stephanie Espiand, do you have any ideas on this? Let's discuss on Slack. |