Jorge Ferrer updated LPS-67802.
Jorge Ferrer commented on LPS-67802.
Jorge Ferrer updated LPS-67555.
Jorge Ferrer commented on LPS-67555.
Jorge Ferrer updated LPS-67399.
Jorge Ferrer updated LPS-67399.
August 29
Jorge Ferrer commented on LPS-67399.
August 8
Jorge Ferrer commented on LPS-66240.
8:24 AM > This seems pretty easy, though I wonder what the Role Action Menu item would say? Still Edit? Correct. The user clicks "Edit" and there are three tabs in the edit screen, each of them has a noun as its label. > This should be easy, but in the design there is currently no menu item to go to the "Assignees" or "Assign Members" page. We would need to add that in order to change the behavior of clicking the role name. Why is that? The new way of going there would be to click "Edit" and then go to the "Assigned Members" tab. This might be worth some testing to check if users (new and existing) have a hard time finding it in the new tab, but it's the way Ivan designed it, so we should stick with it unless proven problematic. >> What do you think of making the default view the descriptive view instead of the table? > No problem, but we should do that everywhere if possible. Wherever it makes sense yes. In some other places (i.e. users) the icon view is clearly a better option. And in some cases I guess a tabular view might be more appropriate. We should come up with clear rules, but I would leave that to the Lexicon UX team to decide since they are evaluating all apps to come up with consistent patterns all the time >> The name has been removed as "Key" and moved down. Also (and this was probably not clear in the mockup) the idea would be to autofill this based on the title (for the default language), with normalization via JavaScript. Is this possible? > This one I don't quite understand. Could you elaborate/give some requirements? The name of a role used to play a double function in the past: as a unique key to refer to certain roles by name programmatically and also as the role name (aka title). When we had the requirement to make the role name/title localizable, a new column called title was added. The column "name" could not be modified because of its usage as a key. This has turned out to be problematic for users since they have two fields (Name and Title) which have the same meaning to them and they have to fill both. To solve this Ivan proposed to leave just title, rename "Name" as "Key" since this is its only reason for existing and move it to a "Configuration" panel so that it's not visible, since it's more of an advanced feature, which is only necessary if the created role is ever going to be accessed programmatically. Also, since the current API requires this field to be non-blank (I think), fill it in automatically based on the title (the value for the default language if there is more than one). Makes sense? > This one is tricky because the fieldset panel is wrapping the custom attributes taglib. If I only changed the taglib, you'd end up with a large empty panel. We'd need to do a conditional wrapping everywhere we used a fieldset to wrap the taglib. I see. How about this? Move the fieldset panel inside the taglib so that all the information to decide whether to render it or not is available. Then (to keep backwards compatibility) create a new taglib attribute called "panel" which defaults to false but can be set to true in order to have the taglib render the panel (if not empty). Sounds good?
July 29
Jorge Ferrer updated LPS-38431.
Jorge Ferrer updated LPS-38431.
Subscribe to Jorge Ferrer's activities. (Opens New Window)