On Sat, Jan 10, 2015 at 8:19 PM, Senaka Fernando <[email protected]> wrote:

> Hi Manu,
>
> Does the layout aspect allow someone to build two or more views for a
> single UI component (i.e. Handhelds vs. Ordinary PCs)? Also, though this is
> non-functional, should we formally define some conventions for styles,
> fonts, logo sizes etc?
>
> Hi Dimuthu,
>
> Shouldn't performance be the #1 priority? Shouldn't we start by setting
> some acceptable performance standards and ensure these are always met?
>

I mean apart from the UX aspects of the components themselves, which
perhaps is not a concern from a framework PoV.

Thanks,
Senaka.

>
> Thanks,
> Senaka.
>
> On Fri, Jan 9, 2015 at 11:40 AM, Dimuthu Leelarathne <[email protected]>
> wrote:
>
>> Hi Manu,
>>
>> You have listed down the required features well. Let me add two
>> none-functional requirements and prioritise them accordingly.
>> 1 - Performance - The UI must be responsive and should not take long to
>> load
>> 2 - Usability - The framework must be easy to grasp for developers and
>> should be easily debuggable
>>
>> And here is my priority.
>> 1 - Componentization
>> 2 - Layout separation
>> 3 - Declarative population
>> 3 - Performance
>> 4 - Usability
>> 5 - Ability to plugin authentication mechanisms
>>
>> Arbitrary overriding and inheritance are good to have things and should
>> not hinder any of the above requirements such as performance or usability.
>>
>> thanks,
>> dimuthu
>>
>> On Mon, Dec 22, 2014 at 7:18 PM, Manuranga Perera <[email protected]> wrote:
>>
>>> In new UI framework we have proposed following features. there were some
>>> concerns about the complexity of the framework due to these “advanced”
>>> features. In this thread I would like to go through each feature and
>>> discusses why we need them. please  contribute your ideas on the usefulness
>>> of each feature.
>>>
>>> 1. Componentization
>>>
>>> UI is made out of components that are self contained. this mean each
>>> component has it’s own CSS/JS/ backend code/HTML it needs to render the UI.
>>> This is the basic feature of the framework.
>>>
>>>
>>> 2. Layout Separation
>>>
>>> Layouts lives separately to the UI. here layout means the basic
>>> structure of the UI, fluid/non-fluid , number of columns, banner and footer
>>> placement etc.
>>>
>>> 3. Declarative Population
>>>
>>> some UI elements (eg: menu) is populated using the information that is
>>> gathered from multiple components. EG: there is no single file that you
>>> can open and find out the structure of the menu, each components pushes
>>> individual links that makes up the whole component.
>>>
>>> usecases
>>>
>>>    -
>>>
>>>    left side navigation menu like in carbon console UI
>>>    -
>>>
>>>    in top navigation bar, cloud needs to add additional links
>>>    -
>>>
>>>    tab views for AM needs documentation tab additionally
>>>
>>>
>>>
>>> 4. Arbitrary overriding
>>>
>>> any part of the UI (granularity depends on implementation) can be
>>> overridden without directly changing the code of that section. you add a
>>> new component and defined what part you should override.
>>>
>>> usecases
>>>
>>>    -
>>>
>>>    Logo needs to change from product to product
>>>    -
>>>
>>>    UI Action needs to change depending on device type/RXT type in
>>>    publisher/CDM
>>>    -
>>>
>>>    Customers need to add sections to header/footer or body.
>>>
>>>
>>> 5. Inheritance
>>>
>>> when you override a component (as in feature 4), you can reuse the
>>> overddin code and just override a part of it. this allows re-use among the
>>> overridden and overriding components. (like extending a java class but only
>>> overriding few methods)
>>>
>>> usecases
>>>
>>>    -
>>>
>>>    If you are overriding the asset view and change the “Subscribe”
>>>    button to “Install”  for a given asset type (eg mobile app) then you 
>>> should
>>>    rewrite the whole code section that renders the item description.
>>>
>>>
>>>
>>>    -
>>>
>>>    If you add a new theme for AM that extended grenic store theme you
>>>    shouldn’t write it from the scratch. the customers should then be able to
>>>    extend it and create their own.
>>>
>>>
>>> WSO2 Generic theme -> Generic Store Theme -> AM Store Theme -> Customer
>>> Store Theme
>>>
>>>
>>>
>>> --
>>> With regards,
>>> *Manu*ranga Perera.
>>>
>>> phone : 071 7 70 20 50
>>> mail : [email protected]
>>>
>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Architect & Product Lead of App Factory
>>
>> WSO2, Inc. (http://wso2.com)
>> email: [email protected]
>> Mobile : 0773661935
>>
>> Lean . Enterprise . Middleware
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
>
> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando*
> Solutions Architect; WSO2 Inc.; http://wso2.com
>
>
>
> *Member; Apache Software Foundation; http://apache.org
> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1
> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>
>
> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
> http://linkedin.com/in/senakafernando
> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>



-- 


*[image: http://wso2.com] <http://wso2.com>Senaka Fernando*
Solutions Architect; WSO2 Inc.; http://wso2.com



*Member; Apache Software Foundation; http://apache.org
<http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408
754 7388; ext: 51736*;


*M: +44 782 741 1966Linked-In: http://linkedin.com/in/senakafernando
<http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to