Re: [xwiki-devs] [Iteration][UX] Extended Breadcrumb
Hi Vincent, The iteration follows two ideas: A. combine the global menu functionality with breadcrumbs (this was again suggested by you when we proposed Macaw skin); B. use trees inside the breadcrumb; I've iterated on A) in order to demonstrate how it will look like, what problems/confusions might appear. My conclusion is that combining the 2 functionalities will increase complexity and cause either harder navigation or confusion (depending if we display or not the entity icons). The solution could be to keep the breadcrumb for navigation, while transferring the global-menu actions inside the content-menu (but this ideally needs to be adaptive - which is again not that straightforward to implement) + Drawer. I've iterated also on B). The usage of tree depends on how many entries we plan to display in the breadcrumb (3, 5+, etc.) in order to provide added value by tree usage. This direction could have further iterations if we want to go this way, like: - provide also actions inside the Tree displayer (still actions needs to be limited + plus think about mobile usage); - have a common activator (we could use the Home icon) or localized tree activator (the mockup displays a localized activator on '...'); - other? Some questions that appeared during this iteration: - what do we do with the parent/child backwards compatibility? - when we have nested spaces, we display the space or the space.webhome? the type of the entry is a space or the page? - how important is to limit the breadcrumb display? usually how many entries we have in a breadcrumb? Should we default for more than 7 entries or keep 3 like we currently have? - how important is to provide fast access for Watch or Delete space actions? or other actions inside the global-menu? Administration and Indexes could be displayed in the Drawer, Watch+Delete inside the content-menu ( http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu) Compared to other proposals (when the 'final' solution was presented), here it was mostly an iteration, exploring possible approaches and requesting feedback or other ideas. Thanks, Caty On Tue, May 26, 2015 at 11:02 AM, vinc...@massol.net vinc...@massol.net wrote: Hi Caty, On 22 May 2015 at 17:39:58, Ecaterina Moraru (Valica) (vali...@gmail.com (mailto:vali...@gmail.com)) wrote: Hi, This is an iteration for: Extended-Breadcrumb's purpose is to provide a solution to *combine* the global-menu functionality with the current breadcrumb functionality, while supporting *nested spaces* concept and being backwards compatible with *parent/child* relationship. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb It’s cool that you started working on this! :) However I don’t understand the conclusion. You say: “The recommendation is to keep separate the navigation (breadcrumb) from entity type actions (menus).“ However the 3 screenshots don’t reflect that since the entity type action have disappeared! Could you explain what’s your proposal for the entity type action menu and how you implement nested spaces in it? Thanks -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Extended Breadcrumb
Another thing to consider: if we alter the global menu, than we will need a new skin IMO. I'm not saying that should be Macaw, but maybe another version of Flamingo. We would need to modify some than a couple of templates. We already changed the menus behavior in Flamingo like 2 times (with the 'Add' button, then with the 'Go to' functionality). Where do we consider the changes are vast enough in order to need another skin? Thanks, Caty On Tue, May 26, 2015 at 11:46 AM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi Vincent, The iteration follows two ideas: A. combine the global menu functionality with breadcrumbs (this was again suggested by you when we proposed Macaw skin); B. use trees inside the breadcrumb; I've iterated on A) in order to demonstrate how it will look like, what problems/confusions might appear. My conclusion is that combining the 2 functionalities will increase complexity and cause either harder navigation or confusion (depending if we display or not the entity icons). The solution could be to keep the breadcrumb for navigation, while transferring the global-menu actions inside the content-menu (but this ideally needs to be adaptive - which is again not that straightforward to implement) + Drawer. I've iterated also on B). The usage of tree depends on how many entries we plan to display in the breadcrumb (3, 5+, etc.) in order to provide added value by tree usage. This direction could have further iterations if we want to go this way, like: - provide also actions inside the Tree displayer (still actions needs to be limited + plus think about mobile usage); - have a common activator (we could use the Home icon) or localized tree activator (the mockup displays a localized activator on '...'); - other? Some questions that appeared during this iteration: - what do we do with the parent/child backwards compatibility? - when we have nested spaces, we display the space or the space.webhome? the type of the entry is a space or the page? - how important is to limit the breadcrumb display? usually how many entries we have in a breadcrumb? Should we default for more than 7 entries or keep 3 like we currently have? - how important is to provide fast access for Watch or Delete space actions? or other actions inside the global-menu? Administration and Indexes could be displayed in the Drawer, Watch+Delete inside the content-menu ( http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu) Compared to other proposals (when the 'final' solution was presented), here it was mostly an iteration, exploring possible approaches and requesting feedback or other ideas. Thanks, Caty On Tue, May 26, 2015 at 11:02 AM, vinc...@massol.net vinc...@massol.net wrote: Hi Caty, On 22 May 2015 at 17:39:58, Ecaterina Moraru (Valica) (vali...@gmail.com (mailto:vali...@gmail.com)) wrote: Hi, This is an iteration for: Extended-Breadcrumb's purpose is to provide a solution to *combine* the global-menu functionality with the current breadcrumb functionality, while supporting *nested spaces* concept and being backwards compatible with *parent/child* relationship. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb It’s cool that you started working on this! :) However I don’t understand the conclusion. You say: “The recommendation is to keep separate the navigation (breadcrumb) from entity type actions (menus).“ However the 3 screenshots don’t reflect that since the entity type action have disappeared! Could you explain what’s your proposal for the entity type action menu and how you implement nested spaces in it? Thanks -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Extended Breadcrumb
On 26 May 2015 at 10:47:13, Ecaterina Moraru (Valica) (vali...@gmail.com(mailto:vali...@gmail.com)) wrote: Hi Vincent, The iteration follows two ideas: A. combine the global menu functionality with breadcrumbs (this was again suggested by you when we proposed Macaw skin); B. use trees inside the breadcrumb; I've iterated on A) in order to demonstrate how it will look like, what problems/confusions might appear. My conclusion is that combining the 2 functionalities will increase complexity and cause either harder navigation or confusion (depending if we display or not the entity icons). Note that the current top level menu is already a navigation menu and it already plays the role of a limited breadcrumb (wiki space page). There are 2 questions I see: 1) what does the top level menu becomes with nested spaces. Following the current logic, if you have Space1 and Space2 you’d have: Wiki Space1 Space2 Page 2) when we implement nested spaces, do we still need the parent/child relationship. My opinion is “no” and we should turn it off by default and keep it only as an advanced feature for those who really need/want it. Once this is said, it means that if we rewrite the breadcrumb based on the current document’s reference we would have the top level menu and the breadcrumb display the same thing (if we follow the current logic), which is probably not good. I’d like to know your proposal for point 1). The solution could be to keep the breadcrumb for navigation, while transferring the global-menu actions inside the content-menu (but this ideally needs to be adaptive - which is again not that straightforward to implement) + Drawer. I've iterated also on B). The usage of tree depends on how many entries we plan to display in the breadcrumb (3, 5+, etc.) in order to provide added value by tree usage. This direction could have further iterations if we want to go this way, like: - provide also actions inside the Tree displayer (still actions needs to be limited + plus think about mobile usage); - have a common activator (we could use the Home icon) or localized tree activator (the mockup displays a localized activator on '...'); - other? Some questions that appeared during this iteration: - what do we do with the parent/child backwards compatibility? See point 2 above - when we have nested spaces, we display the space or the space.webhome? the type of the entry is a space or the page? I don’t understand the question. - how important is to limit the breadcrumb display? usually how many entries we have in a breadcrumb? Should we default for more than 7 entries or keep 3 like we currently have? I don’t understand. Currently the breadcrumb allows for more than 3 entries... - how important is to provide fast access for Watch or Delete space actions? or other actions inside the global-menu? Administration and Indexes could be displayed in the Drawer, Watch+Delete inside the content-menu ( http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu) Note that it’s more than just Watch/Delete space: - watch space - space admin - space index pages - delete space Note that IMO http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu is missing a Space Index menu entry to make it relatively simple to navigate to any space from anywhere (and thus we able to watch/delete/etc). I have 2 solutions that I would find nice: Solution 1 == - drawer menu as on http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu (+ something to navigate easily to any space) - keep the current breadcrumb location but base it on the reference (instead of parent-child) - add the ability to click on any element of the breadcrumb to perform the actions that are currently in the top level menu (but don’t make is visible, ie keep the current LF, it’s only when you hover or click on an element that you get a dropdown, making it a “hidden/advanced” feature like: https://www.evernote.com/l/AHect8iy7ylGWLtlW0uvk2pvkenGBiMFcDQ Solution 2 == - drawer menu as on http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu (+ something to navigate easily to any space) - keep the current breadcrumb location but base it on the reference (instead of parent-child) - add the ability to click on any element of the breadcrumb but when you click on them you get a dropdown with all children of the current element (using a treeview set on the children of the current element). With solution 2 you wouldn’t have the actions anymore and you’d need to navigate to the element to get its actions. OTOH you’d get a quick way to navigate a bit everywhere from your current location. I’m hesitating between both solutions. They solve different needs. Thanks -Vincent Compared to other proposals (when the 'final' solution was presented), here it was mostly an iteration, exploring possible approaches and requesting feedback or
Re: [xwiki-devs] [Iteration][UX] Extended Breadcrumb
Hi, On 26 May 2015 at 10:53:44, Ecaterina Moraru (Valica) (vali...@gmail.com(mailto:vali...@gmail.com)) wrote: Another thing to consider: if we alter the global menu, than we will need a new skin IMO. I'm not saying that should be Macaw, but maybe another version of Flamingo. We would need to modify some than a couple of templates. We already changed the menus behavior in Flamingo like 2 times (with the 'Add' button, then with the 'Go to' functionality). Where do we consider the changes are vast enough in order to need another skin? I don’t agree that it would need a new skin. I’d much prefer that we make the menu elements configurable within a skin. We need that anyway. On a technical level it could mean that top level menu and breadcrumb locations would be UIX. Thanks -Vincent Thanks, Caty On Tue, May 26, 2015 at 11:46 AM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi Vincent, The iteration follows two ideas: A. combine the global menu functionality with breadcrumbs (this was again suggested by you when we proposed Macaw skin); B. use trees inside the breadcrumb; I've iterated on A) in order to demonstrate how it will look like, what problems/confusions might appear. My conclusion is that combining the 2 functionalities will increase complexity and cause either harder navigation or confusion (depending if we display or not the entity icons). The solution could be to keep the breadcrumb for navigation, while transferring the global-menu actions inside the content-menu (but this ideally needs to be adaptive - which is again not that straightforward to implement) + Drawer. I've iterated also on B). The usage of tree depends on how many entries we plan to display in the breadcrumb (3, 5+, etc.) in order to provide added value by tree usage. This direction could have further iterations if we want to go this way, like: - provide also actions inside the Tree displayer (still actions needs to be limited + plus think about mobile usage); - have a common activator (we could use the Home icon) or localized tree activator (the mockup displays a localized activator on '...'); - other? Some questions that appeared during this iteration: - what do we do with the parent/child backwards compatibility? - when we have nested spaces, we display the space or the space.webhome? the type of the entry is a space or the page? - how important is to limit the breadcrumb display? usually how many entries we have in a breadcrumb? Should we default for more than 7 entries or keep 3 like we currently have? - how important is to provide fast access for Watch or Delete space actions? or other actions inside the global-menu? Administration and Indexes could be displayed in the Drawer, Watch+Delete inside the content-menu ( http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu) Compared to other proposals (when the 'final' solution was presented), here it was mostly an iteration, exploring possible approaches and requesting feedback or other ideas. Thanks, Caty On Tue, May 26, 2015 at 11:02 AM, vinc...@massol.net wrote: Hi Caty, On 22 May 2015 at 17:39:58, Ecaterina Moraru (Valica) (vali...@gmail.com (mailto:vali...@gmail.com)) wrote: Hi, This is an iteration for: Extended-Breadcrumb's purpose is to provide a solution to *combine* the global-menu functionality with the current breadcrumb functionality, while supporting *nested spaces* concept and being backwards compatible with *parent/child* relationship. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb It’s cool that you started working on this! :) However I don’t understand the conclusion. You say: “The recommendation is to keep separate the navigation (breadcrumb) from entity type actions (menus).“ However the 3 screenshots don’t reflect that since the entity type action have disappeared! Could you explain what’s your proposal for the entity type action menu and how you implement nested spaces in it? Thanks -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Extended Breadcrumb
Hi Caty, On 22 May 2015 at 17:39:58, Ecaterina Moraru (Valica) (vali...@gmail.com(mailto:vali...@gmail.com)) wrote: Hi, This is an iteration for: Extended-Breadcrumb's purpose is to provide a solution to *combine* the global-menu functionality with the current breadcrumb functionality, while supporting *nested spaces* concept and being backwards compatible with *parent/child* relationship. Proposal: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb It’s cool that you started working on this! :) However I don’t understand the conclusion. You say: “The recommendation is to keep separate the navigation (breadcrumb) from entity type actions (menus).“ However the 3 screenshots don’t reflect that since the entity type action have disappeared! Could you explain what’s your proposal for the entity type action menu and how you implement nested spaces in it? Thanks -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Bug in getusers.vm?
Hi Caleb,
On 25 May 2015 at 02:54:44, Caleb James DeLisle
(c...@cjdns.fr(mailto:c...@cjdns.fr)) wrote:
That's not bad velocity, that's bad javascript.
ah indeed… Not easy to read :)
Ideally you never
mix velocity and js but the best way I've found when it must be done
is to isolate all of the generated js at the top of the script, eg:
// BEGIN VELOCITY
var EXTRA_ANCHOR_LINK = ${extraAnchor}link;
var TM_SHOW_EXTRA_ANCHOR = tmShow${extraAnchor}
// END VELOCITY
...
later
...
if ($(EXTRA_ANCHOR_LINK) != null) { ...
Note #1: I've still not found a solution to stopping the velocity
parser from evaluating below a certain point.
#stop ?
See http://velocity.apache.org/engine/releases/velocity-1.7/user-guide.html#Stop
Note #2: There is also the issue of using != instead of !== which
increases bugs in js (but don't change it now because it might be
relying on the implicit casting).
Thanks
-Vincent
Thanks,
Caleb
On 05/23/2015 06:02 PM, vinc...@massol.net wrote:
BTW I see several places where we have:
if ($(${extraAnchor}link) != null) {
if ($(tmShow${extraAnchor}) != null) {
…
This doesn’t seem right either…
According to http://wiki.apache.org/velocity/CheckingForNull this is not
how to check for null.
WDYT?
Thanks
-Vincent
On 23 May 2015 at 17:58:51, vinc...@massol.net (vinc...@massol.net) wrote:
Hi Caleb,
On 23 May 2015 at 16:28:17, Caleb James DeLisle
(c...@cjdns.fr(mailto:c...@cjdns.fr)) wrote:
Agreed, I can't see what that line should do, if anything.
The best it can do is add a null element to the list, kicking the value to
index 1.
“null” doesn’t exist in velocity AFAIK so the statement is even invalid IMO
(see below).
As for the thinking of the author, the comment implies he didn't clarify
his thinking
about what was being done and why so I'd favor simply dropping the line
and doing a
few basic (manual) does it still work tests to be sure.
No it’s more complex than that, I think the author meant:
#set( $discard = $arr.add( $NULL ) ) ## this may be variable...
If you check the vm the code is:
#set( $discard = $arr.add( null ) ) ## this may be variable...
#set( $discard = $arr.add( $value ) )
#set( $discard = $filterMap.put($key, $arr))
Thus it builds a 2 element list which is then put in a map. This map is
passed to getAllMatchedLocalUsers() (for ex), which says in its javadoc:
* @param matchFields the fields to match. It is a Map with field name as
key and for value :
*
*
matching string for document fields
*
or [field type, matching string] for object fields
*
The javadoc doesn’t mention the support for null as the key. However
following the source code it seems to lead to
getAllMatchedLocalUsersOrGroups() which has a more useful javadoc:
fieldtype : for example StringProperty. If null the field is considered as
document field
Thus it seems the author really wanted to pass null and that would be $NULL.
Ok I’ve checked in a page the result of:
{{velocity}}
#set ($arr = [])
#set( $discard = $arr.add( null ) ) ## this may be variable...
#set( $discard = $arr.add( value ) )
$arr
{{/velocity}}
and strangely enough it gives [null, value] :)
So even if invalid it still puts null.
Anyway fixing by using $NULL
Thanks
-Vincent
Thanks,
Caleb
On 05/23/2015 10:56 AM, vinc...@massol.net wrote:
Hi devs,
I’ve noticed the following in getusers.vm:
#set ($arr = [])
#set( $discard = $arr.add( null ) ) ## this may be variable...
#set( $discard = $arr.add( $value ) )
The “null” part doesn’t seem correct at all and I don’t understand the
comment ## this may be variable…”
Any idea what the original author wanted to do?
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Bug in getusers.vm?
Note #1: I've still not found a solution to stopping the velocity parser from evaluating below a certain point. #stop ? See http://velocity.apache.org/engine/releases/velocity-1.7/user-guide.html#Stop That stops the rendering as well, and we want to get all the JS code that comes afterwards. Maybe #[[ ... ]]# is what we want? http://velocity.apache.org/engine/devel/vtl-reference-guide.html#Unparsed_Content It depends on not having ]]# present in the source, but I guess that's fine since we would explicitly use this when needed. -- Sergiu Dumitriu http://purl.org/net/sergiu ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
