Customizable UI Definition

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

Village****Reach* ** 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

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

···

On Tue, Dec 8, 2015 at 1:58 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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

Village****Reach* ** 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

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_committee+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis_product_committee@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
Email
rorser@thoughtworks.com
Telephone
+1-646-632-7926, +27-720841843
ThoughtWorks

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

Village****Reach* ** 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 rorser@thoughtworks.com

Sent: Monday, December 7, 2015 22:20

To: Kevin Cussen

Cc: openlmis_product_committee@googlegroups.com

Subject: Re: Customizable UI Definition

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

On Tue, Dec 8, 2015 at 1:58 AM, Kevin Cussen
kevin.cussen@villagereach.org wrote:

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*

Village****Reach* ** 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

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_committee+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis_product_committee@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
Email
rorser@thoughtworks.com
Telephone
+1-646-632-7926, +27-720841843
ThoughtWorks

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

Village****Reach* ** 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_product_committee@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

On Dec 8, 2015, at 5:24 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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*

Village****Reach* ** 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 rorser@thoughtworks.com

Sent: Monday, December 7, 2015 22:20

To: Kevin Cussen

Cc: openlmis_product_committee@googlegroups.com

Subject: Re: Customizable UI Definition

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

On Tue, Dec 8, 2015 at 1:58 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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*

Village****Reach* ** 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

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 toopenlmis_product_committee+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis_product_committee@googlegroups.com.

To view this discussion on the web visithttps://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
Email
rorser@thoughtworks.com
Telephone
+1-646-632-7926, +27-720841843
ThoughtWorks

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

···

On Tue, Dec 15, 2015 at 1:17 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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

Village****Reach* ** 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


Subject: Re: Customizable UI Definition

From: Josh Zamor

Sent: Monday, December 14, 2015 12:40

To: Kevin Cussen

Cc: Renee Orser; openlmis_product_committee@googlegroups.com; Rich Magnuson; Ben Leibert; Chongsun Ahn

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

On Dec 8, 2015, at 5:24 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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*

Village****Reach* ** 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 rorser@thoughtworks.com

Sent: Monday, December 7, 2015 22:20

To: Kevin Cussen

Cc: openlmis_product_committee@googlegroups.com

Subject: Re: Customizable UI Definition

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_committee+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis_product_committee@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis_product_committee/CY1PR02MB11194025A7964FF2656CD296E3ED0%40CY1PR02MB1119.namprd02.prod.outlook.com.

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

On Tue, Dec 8, 2015 at 1:58 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

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*

Village****Reach* ** 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

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 toopenlmis_product_committee+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis_product_committee@googlegroups.com.

To view this discussion on the web visithttps://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
Email
rorser@thoughtworks.com
Telephone
+1-646-632-7926, +27-720841843
ThoughtWorks

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