Search: concept

mails : * [UX] Wiki - Space - Page concepts pitch http://markmail.org/thread/7y62ewmo2ltdeomq (Jul 31, 2014)

In the code, there actually exists the concept of a syntax in which translations are written.

In the code, there actually exists the concept of a syntax in which translations are written. 1.

Global Administration Before Display all existing users and groups with empty or explicit states After Display just the users/groups that have explicit values for rights User will need to manually add the user/group they want to provide explicit rights Wiki Administration Before After Compacted mode for the display of 'Users' and 'Groups' Local Wiki groups properly marked Page Administration Before After 'Page' and 'Page & Children' compacted into a single 'Page' category Terminal pages are considered a deprecated concept, so we reduce this feature's visibility Page only rights can still be set by advanced users from Object editor or Rights editor 'Creator' implied rights displayed for clarity

{{toc start="2" /}} == Changes == === Buttons === (%class="row"%)((( (%class="col-xs-6"%)((( {{gallery}} image:right_before.png {{/gallery}} Before * Only explicit allow/deny states are displayed ))) (%class="col-xs-6"%)((( {{gallery}} image:right_button_states.png image:right_button_examples.png image:rights_implied.png {{/gallery}} After * Use 3-states-buttons to allow explicit values and also display the default/inherited/implied values * Clearly mark implicit rights (for example when explicitly selecting 'Admin' also marked the implied rights 'View', 'Edit', etc.) ))) ))) === Global Administration === (%class="row"%)((( (%class="col-xs-6"%)((( {{gallery}} image:before_G_groups.png image:before_G_users.png image:before_G_create_groups.png image:before_G_create_users.png {{/gallery}} Before * Display all existing users and groups with empty or explicit states ))) (%class="col-xs-6"%)((( {{gallery}} image:after_G.png {{/gallery}} After * Display just the users/groups that have explicit values for rights * User will need to manually add the user/group they want to provide explicit rights ))) ))) === Wiki Administration === (%class="row"%)((( (%class="col-xs-6"%)((( {{gallery}} image:before_W_groups_L.png image:before_W_groups_B.png image:before_W_users.png {{/gallery}} Before ))) (%class="col-xs-6"%)((( {{gallery}} image:after_W.png image:after_W_filter.png {{/gallery}} After * Compacted mode for the display of 'Users' and 'Groups' * Local Wiki groups properly marked ))) ))) === Page Administration === (%class="row"%)((( (%class="col-xs-6"%)((( {{gallery}} image:before_P_PC_groups.png image:before_P_PC_users.png image:before_P_P_groups.png image:before_P_P_users.png {{/gallery}} Before ))) (%class="col-xs-6"%)((( {{gallery}} image:after_P.png {{/gallery}} After * 'Page' and 'Page & Children' compacted into a single 'Page' category ** Terminal pages are considered a deprecated concept, so we reduce this feature's visibility ** Page only rights can still be set by advanced users from Object editor or Rights editor * 'Creator' implied rights displayed for clarity ))) )))

However, to validate concepts and expected path of our users, a rough wireframe can be sufficient.

However, to validate concepts and expected path of our users, a rough wireframe can be sufficient. == By whom?

Application Bar With this proposal, the concept of applications bar is not needed anymore.

. == Application Bar == With this proposal, the concept of [[applications bar>>doc:AppBar]] is not needed anymore.

At the very least a user would need to be able to know: - if the page is followed for all events - if the page is blocked for all events - if the page has no specific state defined (i.e. the default behaviour, i.e. unfollowed, is used for it) - if the page has a partial/custom filter defined Ideally we need icons that represents those concepts. Using bells not set: followed: blocked: custom: Other proposal using volume I (Simon) find the volume concept interesting for notifications since there's a lot of variability in it, that can be used to express the different states.

At the very least a user would need to be able to know: - if the page is followed for all events - if the page is blocked for all events - if the page has no specific state defined (i.e. the default behaviour, i.e. unfollowed, is used for it) - if the page has a partial/custom filter defined Ideally we need icons that represents those concepts. ==== Using bells ==== * not set: [[image:1690467909473-475.png]] * followed: [[image:1690467924308-770.png]] * blocked: [[image:1690467946417-567.png]] * custom: [[image:1690467989728-366.png]] ==== Other proposal using volume ==== I (Simon) find the volume concept interesting for notifications since there's a lot of variability in it, that can be used to express the different states.

Drawer Activator Drawer View Iteration 2 This proposal consider a Nested Documents use case, where Spaces and Pages are replaced with a single Node (Page) concept. The entities hierarchy transforms in: Main Wiki > Sub Wiki > Pages > Child Pages Wikis are used to isolate Applications and Pages The View mode displays Applications and Pages of the current Wiki Wikis will be displayed in a separate way than Pages They have their own Index app + Drawer provides a special listing for them The proposal moves: Wiki actions from global menu into Drawer and Wiki Index Wiki navigation from global menu to Breadcrumb and Drawer Summary: Drawer will contain: Profile Navigation, Wiki Actions, Wiki Navigation Breadcrumb will contain: Wiki Navigation, Page Navigation Wiki Index will contain: Wiki Actions, Wiki Navigation Breadcrumb Read more about Extended Breadcrumbs Structure User Avatar + Profile link Log-out link (Current) Wiki Actions Administrator specific User specific Indexes Wiki Navigation Wiki list Add wiki Examples Main Wiki - Normal user Main Wiki - Admin user Sub Wiki - Admin user

(% class="row" %) ((( (% class="col-xs-12" %) ((( == Before == ))) (% class="col-xs-6" %) ((( [[{{image reference="[email protected]" width="100%"/}}>>attach:before.png]] ))) (% class="col-xs-6" %) ((( **Purpose**: Removing global menu from UI means finding a new place to display navigation and actions for wikis and pages. ))) ))) (% class="row" %) ((( (% class="col-xs-12" %) ((( == Iteration 1 == ))) (% class="col-xs-12" %) ((( The first iteration of Drawer was part of the [[Macaw Skin>>Proposal.MacawSkin]] proposal. ))) (% class="col-xs-6" %) ((( Drawer Activator [[{{image reference="drawerActivator.png" width="100%"/}}>>attach:drawerActivator.png]] ))) (% class="col-xs-6" %) ((( Drawer View [[{{image reference="drawerInitial.png" width="100%"/}}>>attach:drawerInitial.png]] ))) ))) (% class="row" %) ((( (% class="col-xs-12" %) ((( == Iteration 2 == ))) (% class="col-xs-8" %) ((( * This proposal consider a Nested Documents use case, where Spaces and Pages are replaced with a single Node (Page) concept. * The entities hierarchy transforms in: ** Main Wiki > Sub Wiki > Pages > Child Pages * Wikis are used to isolate Applications and Pages ** The View mode displays Applications and Pages of the current Wiki ** Wikis will be displayed in a separate way than Pages *** They have their own Index app + Drawer provides a special listing for them * The proposal moves: ** Wiki actions from global menu into Drawer and Wiki Index ** Wiki navigation from global menu to Breadcrumb and Drawer * Summary: ** Drawer will contain: Profile Navigation, Wiki Actions, Wiki Navigation ** Breadcrumb will contain: Wiki Navigation, Page Navigation ** Wiki Index will contain: Wiki Actions, Wiki Navigation ))) (% class="col-xs-4" %) ((( Breadcrumb [[{{image reference="breadcrumb.png" width="100%"/}}>>attach:breadcrumb.png]] Read more about [[Extended Breadcrumbs>>Proposal.ExtendedBreadcrumb]] ))) ))) (% class="row" %) ((( (% class="col-xs-12" %) ((( === Structure === ))) (% class="col-xs-6" %) ((( [[{{image reference="drawerStructure.png" width="100%"/}}>>attach:drawerStructure.png]] ))) (% class="col-xs-6" %) ((( * User ** Avatar + Profile link ** Log-out link * (Current) Wiki Actions ** Administrator specific ** User specific ** Indexes * Wiki Navigation ** Wiki list ** Add wiki ))) ))) (% class="row" %) ((( (% class="col-xs-12" %) ((( === Examples === ))) (% class="col-xs-4" %) ((( Main Wiki - Normal user [[{{image reference="NormalMainWiki.png" width="100%"/}}>>attach:NormalMainWiki.png]] ))) (% class="col-xs-4" %) ((( Main Wiki - Admin user [[{{image reference="AdminMainWiki.png" width="100%"/}}>>attach:AdminMainWiki.png]] ))) (% class="col-xs-4" %) ((( Sub Wiki - Admin user [[{{image reference="AdminSubwiki.png" width="100%"/}}>>attach:AdminSubwiki.png]] ))) )))

Needed adjustment only on content menu O: users don't always understand the meaning of icons (and what the icon designer wanted to mean) + all studies lead to the same conclusion about labels O: user doesn't know what category of items are contained in the 2 menus The content menu is floating in the air Problematic wiki concept since people don't know pages can be edited and they are not invited to do it.

Needed adjustment only on content menu * O: users don't always understand the meaning of icons (and what the icon designer wanted to mean) + all studies lead to the same conclusion about labels * O: user doesn't know what category of items are contained in the 2 menus * The content menu is floating in the air * Problematic wiki concept since people don't know pages can be edited and they are not invited to do it.

xwiki-platform-discussion-api: Provides the operations to interact with the discussions xwiki-platform-discussion-default: Default implementation of the discussions API xwiki-platform-discussion-rest: Provides the REST operations to interact with the discussion xwiki-platform-discussion-store-api: Provides the operations to interact with the discussion store xwiki-platform-discussion-store-default: Default implementation of the store API, where the discussion entities are stored in xpages xwiki-platform-discussion-ui: Provides the generic user interfaces of the discussions as well as reusable macros to integrate the discussions contextually in XWiki's interfaces Domain Overview This section describes the main concepts manipulated in the context of the discussions Discussion Context A discussion context represents a group of discussions sharing a relation to the same entity.

= Table of content = {{toc numbered="true"/}} = Architecture Overview = (% class="box warningmessage" %) ((( The proposed name for the application is //discussion//, it will be used in the remainder of the document but might be subject to change. ))) (% class="box warningmessage" %) ((( I'm also considering it to be part of xwiki platform for the naming, but that also might change. ))) * ##xwiki-platform-discussion-api##: Provides the operations to interact with the discussions * ##xwiki-platform-discussion-default##: Default implementation of the discussions API * ##xwiki-platform-discussion-rest##: Provides the REST operations to interact with the discussion * ##xwiki-platform-discussion-store-api##: Provides the operations to interact with the discussion store * ##xwiki-platform-discussion-store-default##: Default implementation of the store API, where the discussion entities are stored in xpages * ##xwiki-platform-discussion-ui##: Provides the generic user interfaces of the discussions as well as reusable macros to integrate the discussions contextually in XWiki's interfaces = Domain Overview = This section describes the main concepts manipulated in the context of the discussions **Discussion Context** A discussion context represents a group of discussions sharing a relation to the same entity.

Static List implies understanding the concept of static and dynamic and also the difference between this field and Database List.

Next step and Previous step buttons have chevrons that indicate visually the direction in which the process is moving Step 1 Ideas Frame Come back on the mockup and change application into collection 1. We explain the concept of collection and records to the user and guide him through the process: Your data is stored as individual records in a collection. let's define this collection. 2.

//Static List// implies understanding the concept of static and dynamic and also the difference between this field and Database List. 1*.

Next step and Previous step buttons have chevrons that indicate visually the direction in which the process is moving )))|(% style="width:590px" %)[[image:AWM- Step1.png]] == **Step 1** == |(% style="width:578px" %)**Ideas**|(% style="width:582px" %)**Frame** |(% style="vertical-align:middle; width:578px" %)((( **__Come back on the mockup and change application into collection__** ~1. We explain the concept of collection and records to the user and guide him through the process: //Your data is stored as individual records in a collection. let's define this collection.// //2.