Customizable UI Definition

5 views
Skip to first unread message

Kevin Cussen

unread,
Dec 7, 2015, 6:58:15 PM12/7/15
to openlmis_prod...@googlegroups.com

Hi all,


Please find an updated description of the "Customizable UI" re-architecture Output ("RAO") incorporating our discussions and your notes below. This is the definition I will begin to create user stories around with the VR dev team. Please comment by EOB, Wednesday, December 9th if you would like to make changes to this RAO.


The OpenLMIS user interface can be customized to specific implementations without forking the code base

 

Epic: Customizable UI

 

Description: Implementers need to be able to customize the UI without modifying the underlying APIs. The underlying APIs needs to remain stable so that countries can take advantage of new features of OpenLMIS without fear of breaking their implementation. OpenLMIS must offer a reference UI that implementers are at liberty to make simple modifications to through configuration screens. The reference UI must strive to be low bandwidth and device agnostic. The following UI elements need to be modifiable via configuration at the implementation level:

·       Branding

·       Language

·       Labels

·       Colors / Color Schemes

The preference is that these features are configurable by an administrator similar to configuration options in Drupal, Salesforce, or Wordpress. However, it is absolutely essential that if UI has to be changed at the code level that developers are able to modify these attributes without modifying the underlying core.

 

Wish List:

·       Ability to configure UI based on user profile


Cheers,


Kevin Cussen

Technology Manager

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

CELL: 1.206.604.4209 

www.villagereach.org

Connect on Facebook, Twitter and our Blog

Renee Orser

unread,
Dec 8, 2015, 1:20:34 AM12/8/15
to Kevin Cussen, openlmis_prod...@googlegroups.com
Hi Kevin,

I think this looks great. My only question is whether language would fall under this theme. Generally I associate "translatability" with code structure, rather than with what a user sees. But I could see us sliding it in here if we don't have another theme that's more appropriate. 

Thanks,
Renee

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Product Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis_product_co...@googlegroups.com.
To post to this group, send email to openlmis_prod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis_product_committee/CY1PR02MB11197C89C1F702F117C6A384E3090%40CY1PR02MB1119.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.



--
Renee Orser
Solution Strategist
Emailror...@thoughtworks.com
Telephone+1-646-632-7926, +27-720841843
ThoughtWorks

Kevin Cussen

unread,
Dec 8, 2015, 8:24:10 PM12/8/15
to Renee Orser, openlmis_prod...@googlegroups.com, Josh Zamor

Hi Renee,


Great question. I'm going to loop in Josh and see if this is the appropriate place to discuss translations or whether there is a better home for it elsewhere.


All - Please bring up any other discussion points by EOB tomorrow.


Cheers,


Kevin Cussen

Technology Manager

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

CELL: 1.206.604.4209 

www.villagereach.org

Connect on Facebook, Twitter and our Blog




From: Renee Orser <ror...@thoughtworks.com>
Sent: Monday, December 7, 2015 22:20
To: Kevin Cussen
Cc: openlmis_prod...@googlegroups.com
Subject: Re: Customizable UI Definition
 

Kevin Cussen

unread,
Dec 14, 2015, 6:17:56 PM12/14/15
to Josh Zamor, openlmis_prod...@googlegroups.com, Rich Magnuson, Ben Leibert, Chongsun Ahn

Hi all,


Thanks Josh for the clarification. It sounds like the idea of translations does indeed exists outside of a customizable UI epic. So - based on this feedback, I'm going to remove language from the UI story and finalize it.


See you all tomorrow morning. 


Cheers,

 

Kevin Cussen

Technology Manager

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

CELL: 1.206.604.4209 

www.villagereach.org

Connect on Facebook, Twitter and our Blog




From: Josh Zamor
Sent: Monday, December 14, 2015 12:40
To: Kevin Cussen
Cc: Renee Orser; openlmis_prod...@googlegroups.com; Rich Magnuson; Ben Leibert; Chongsun Ahn

Subject: Re: Customizable UI Definition
 
Hi Renee,

Okay, you’re going to get a bit of a mix of engineering and deployment process mixed together.  As well as current state and thoughts on future state.

This is one of those cross-cutting concerns we’re thinking about in the re-architecture.  Human language translatable messages start as keys such as “upload.record.error”.  The keys and the original intention of a message should come from the code and the developer that created it for a specific intention - e.g. an error message, a label, etc

In reality the actual message used is often “translated” or changed for an implementation to target their program terminology.  e.g. instead of using "Processing Period" which is an OpenLMIS term for a period of time that could be any number of months, our push-based systems tend to use “Month” as each processing period is simply a month long in the EPI programs.  This is then actually translated into Portuguese, French, etc…

This is the default answer, however it needs to go a step further.  The above describes the situation for the server-code, however it also describes the browser-based code as well as this code can really be seen as another application that is a client to the server.  Moving into the re-architecture I don’t think these responsibilities will change, however I do think we will need to be more granular about what code component / module “owns” a message key.  Code that owns a message key owns the intention behind that key, weather or not client code chooses to utilize it or “translate” it into it’s own intention.  Human language translation and implementation level use is perhaps one of the last aspects in a deployment and so far I think that process, while tedious, is still working well when managed through a tool like Transifex.

Thoughts?

Hopefully this adds some clarity!

Best,
Josh



For more options, visit https://groups.google.com/d/optout.

Renee Orser

unread,
Dec 15, 2015, 2:23:23 AM12/15/15
to Kevin Cussen, Kai Wuhan Dev Hu, Josh Zamor, openlmis_prod...@googlegroups.com, Rich Magnuson, Ben Leibert, Chongsun Ahn
Hi Josh,

Yes, it definitely helps, and confirms my understanding as well. 

We are stepping into a big translation push using Transifex, and I was just speaking yesterday with Kai, our developer who is leading this, about how to reflect our architecture and "ownership" in the codebase in the projects we set up in Transifex. 

I've cc'd Kai here so he can see what you wrote about it. Since we are moving through this set-up in the next couple of weeks, if there is anything you would like us to do anticipating rearchitecture changes to translation management, let's please make sure to discuss it during the tech group call tomorrow.

Thanks!

Renee


For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages