Re: [gatein-dev] [GateIn Portal Development] - Gatein Mobile Detection And Redirection: Administration UI

Indeed it makes it more clear :) I'm sending a different interaction proposal. If we add two lists, we need two Add buttons to specify in which list are you adding a item or if we keep a button, we need to have one more step (drop down) to specify in which list to add the item. Considering that the user needs to fill at least one contains condition, I put an initial input inviting him to fill it. Once he press enter, the input becomes a element that can be removed by clicking in the "x". This way I think we have a much faster and easier interaction. I'm just not sure how many conditions will we have. I expect to have one line of conditions for each type but having two lines would not be a problem. I tried to make it evident by presenting the following message in the initial state: "At least one element for the redirection to happen." and by labeling the second line as "and does not contain". This requires some high IT knowledge. So just to be sure, the person who will set it up is a Admin, a IT guy? Does he already knows that (*) means like "all"? Should not we use another notation, like work "all" or something like that? That's a good idea that I borrowed to apply in the "contains" condition too. Thoughts? Gabriel On Apr 12, 2012, at 5:22 PM, Matt Wringe wrote: > cc'ing back in the gatein-dev list, you should usually use > 'reply-all' (or reply-to-list) so that the list gets added. It's usually > best to discuss things on the list so that the whole group can comment. > > On Thu, 2012-04-12 at 15:41 -0300, Gabriel Cardoso wrote: >> Hi Matt. >> Would that work? Just adding the words OR and AND before the specs? >> Thanks > > No, not exactly (but its my fault its confusing and I should have > specified two separate lists from the original mockups). Can you change > the mock up to add two separate lists for contains and must not contain? > > Really what is comes down to is: > > Contains: > foo > or bar > or ... > > Must Not Contain: > abc > or xyz > or ... > > So if we have a match for anything in the contains list, and we don't > have a match for anything in the 'does-not-contains' list, then the > condition for user agent strings is true. Its the same thing as a white > list and a black list. > > For example, using the above configuration > > User-Agent: fasdfl asdf asdf asdf foo asdf asdf a dsf > -> is true because it contains foo _and_ does not contain abc and xyz > > User-Agent: fasdfl asdf asdf asdf foo abc asdf asdf a dsf > -> is false, even though it contains foo, because it contains abc it > fails > > User-Agent: fasdfl asdf asdf asdf asdf asdf a dsf > -> is false, there is no match on a contains > > User-Agent: fasdfl asdf abc asdf asdf asdf asdf a dsf > -> is false, it contains abc which is in the does-not-contain list (and > it also doesn't contain anything in the contains list) > > > For the situation when you create a new condition, the contains list and > the doesn-not-contain list should probably both be empty (since the > contains list is empty, the default will be to never redirect until the > admin configures something here). > > If we have one or more device properties specified, then _all_ of these > properties must be met (ie its now using AND). > > > So it all works something like this (note: this is for higher level > logic, the implementation doesn't exactly follow these steps). > > 1) we check if the User-Agent string has a match in the list of > 'contains'. If true continue, if not don't do the redirect > > 2) we check if the User-Agent string has a match in the list of 'does > not contain'. If we have a match, then don't do the redirect. Otherwise > continue > > 3) we check if there is a match for all the device properties. If we > have a match, now we can do the redirect, otherwise don't do the > redirect. > > >> >> >> On Apr 12, 2012, at 3:09 PM, Matt Wringe wrote: >> >>> >>> JBoss Community >>> Gatein Mobile Detection And Redirection: Administration UI >>> new comment by Matt Wringe View all comments on this document >>> After a offline discussion, the following changes were determined: >>> >>> >>> - no more concept of device type >>> >>> - prepopulate a new portal with a couple of default redirects which contain default conditions for some specific devices (phone, tablet, etc..) >>> >>> >>> screen 1: >>> >>> - remove the icon and change 'Device' to something like 'Redirect' which will display the redirect name. >>> >>> - add a 'copy' option to clone a new redirect based on a exiting redirect. Copy and Delete will appear under a separate menu where the current 'delete' icon is currently located >>> >>> >>> screen 2: >>> >>> - removed >>> >>> - when creating a new redirect, screen 3 will be displayed. >>> >>> >>> screen 3: >>> >>> - no icon beside the redirect name. >>> >>> - when creating a new redirect: generic redirect name ('redirect-1' or something similar) but its an editable value, so it change be changed. The redirect site will have to be set to the first site name in the drop down [does this make sense? or should it be empty/null by default?]. Redirect will be enabled by default when creating a new redirect [right? since they obviously want to use the redirect, otherwise why would they create one?] [Note this part as not discussed, just adding my thoughts here] >>> >>> - make the 'redirect to' more prominent (larger font size, etc. Its too small and out of the way right now when its an important option) >>> >>> >>> screen 4: >>> >>> TODO: make clearer in screen 4 the behaviour when multiple conditions are specified. >>> >>> Current behaviour for user-agent string: Condition is true if the user agent contains any of the strings specified in 'contains' and no string specified in 'does not contain' >>> >>> [multiple user-agent conditions act as OR] >>> >>> Current behabiour for device properties: If ALL the device conditions are met >>> >>> [multiple device properties act as AND] >>> >>> >>> The idea behind this is that you would probably want to list multiple different contains for a user agent string (ie for a list of browser types, so OR) but you would probably want to use AND for device properties (ie if width is less than X and device pixel density is above y). But this gets a bit confusing. I would rather not have to support more complex rules if possible. >>> >> > >