UX/UI wishlist

[flathat]

I'd like to use this Issue for ideas and discussion of User Experience and User Interface. As with the other Wishlist #374 some may peel off to their own issues for development.

Among them, with some illustrations:

• Consistency of look and behaviour
  • Text size and colour and what they imply
  • Placement of control buttons
  • Additions and changes to CSS and JS libraries
• Description of layout options such as left-side, top or no menus in Fannie
• Possible guidelines for reports and forms
  • Style and content of headings
  • Use of icons for the create, read, update and delete operations
  • Tips on using sortable column heads
• Notices about new features such as
  • the qtips.jquery.js ?-icon two-level inline help
  • auto-completes and/vs. <select>
• Awareness of writing for different scenarios, co-ops with e.g. regular staff with specialized jobs vs staff often seeing a report or interface for the first time
  • Discussion of embedded/inline help and/vs. external documentation
  • Use of gettext(), alias _(), to support localization of labels and messages.
• Tradeoffs involved in using some techniques, e.g. auto-summing of columns in FannieReportPage vs formatting numbers with commas for ease of reading.

[flathat]

Re: Regular report heading Currently some reports have headings and others don't, and styles vary. I suggest a heading like this for reports of class FannieReportPage:

General Day Report (only if window dressing is off) For Thursday, August 21, 2014 (for a single day) From Friday, August 15, 2014 to Thursday, August 21, 2014 (for a range of days) As at: Thursday, August 21, 2014 4:50PM (Smaller, only if the report includes the current day)

This isn't very handsome compared to the Fannie banner/nav. Flush left is right for this report but centered would be better for others.

    function report_description_content() {
        $d1 = FormLib::get_form_value('date1');
        $d2 = FormLib::get_form_value('date2');
        if ($d2 == '') {
            $d2 = $d1;
        }
        $ret = array();
        $asAt = ($d2 == date('Y-m-d')) ?
            "<h3>" . _("As at: ") . date("l, F j, Y g:i A") . "</h3>" :
            '';
        list($year,$month,$day) = explode('-',$d1);
        $fromDate = date("l, F j, Y", mktime(0,0,0,$month,$day,$year));
        list($year,$month,$day) = explode('-',$d2);
        $toDate = date("l, F j, Y", mktime(0,0,0,$month,$day,$year));
        $ret[] = sprintf("<h2>%s%s</h2>%s",
            // Don't duplicate Fannie's header.
            ($this->window_dressing) ? '' : $this->header.'<br />',
            ($d1 == $d2) ? _("For ").$fromDate : _("From ").$fromDate._(" to ").$toDate,
            "$asAt");
        // Whitespace before the next block.
        $ret[] .= "<p> </p>";
        return $ret;
        // If empty return a paragraph rather than '';
        //return(array('<p> </p>'));
    }

Updated with BUGFIX to explode() for $toDate

[flathat]

Re: Fannie src/style.css I'm curious about the overrides, particularly making <h4> larger than <h3>, and nothing for <h1>. Was this for a specialized use that might be better done with a class leaving more default relationships for ordinary use? Or else make a set in src/css/reports.css for report headings.

h2 {
font-size: 1.6em;
line-height: 1.8em;
}
h3 {
font-size: 1.2em;
font-weight: bolder;
line-height: 0.8em;
}
h4 {
font-size: 1.4em;
line-height: 1.4em;
letter-spacing: 0.2em;
}

[gohanman]

For simplicity, I think it would make sense to keep this discussion confined to Fannie. I really like the idea of developing a style guide. That's not to suggest the lane UI is perfect. I just think the two pieces are sufficiently different that it would need two separate style guides. One thing at a time would be more manageable.

I don't think embedded help - as tooltips, links to documentation, or some combination thereof - should be specific to staff experience. It's a good idea regardless.

The commas in numbers might be a unique edge case. The real problem is if you add it two numeric strings containing commas in PHP, the result is another number. It's just not the correct sum. This winds up being a really subtle bug in the context of reporting. Unless someone actually adds the individual values manually, they may not realize the total is wrong. You can work around it, of course, by stripping the commas out before adding. My concern is it's a simple mistake to make, a difficult mistake to notice, and leads to fairly significant inaccuracy. Hopefully there aren't many similar situations.

I think the first big question is how drastic of a change is desired. I could see different potential scopes of this project.

1. We could go with a full-fledged templating engine like Twig to separate data from markup. It would add some to the learning curve for new developers, but they're powerful tools. I worry about this less now that plugins exist as a place for tinkering / ignoring rules, but accessibility still matters. The target audience still potentially includes IT staff with minimal development background and I don't want to discourage participation.
2. We could go with a CSS framework like Bootstrap. This would be more transparent. Coding doesn't really need to change and the style just applies. This would mostly involve resolving conflicts between existing css files & the framework plus tearing out inlined styles. A limited list of acceptable uses for inline styles probably belongs in the UI guide regardless. This doesn't have to be 3rd party, but I don't get the impression anybody's gung-ho about writing a robust modern stylesheet.
3. No overhaul at all. Just focus on improving consistency and inline documentation.

I would lean towards starting at number 2 and proceeding into 3. Having the widgets and icons and such to choose from would make it easier to implement consistent look and feel. I know I have an easier time choosing from a concrete set of options as opposed to trying to invent each piece from scratch. I'm not opposed to any of them though. Twig and Bootstrap were meant as examples. It wouldn't have to be that template engine or CSS framework.

Once the style guide is done, it will be important to file bugs against incorrectly styled pages. Developers will forget. I know, with certainty, that I will occasionally forget. It's a lot like proof reading. The original author doesn't always see the mistakes.

[gohanman]

RE: reporting: that's a good idea and can probably be pushed up into FannieReportPage itself as a helper function. Child reports can get the default description lines then add as needed. I'd vote for always left-aligned. If the report gets downloaded as CSV or XLS, those lines will end up left-aligned. Might as well have it the same across all formats.

RE: header tags: beats me. I inherited most of the CSS. The flyout menus are the only part I've spent a bunch of time on.

[joelbrock]

In general i think a more modern (and consistent) UI would give users renewed confidence in the softeware, and address a number of commonly posed questions. FWIW: i agree with Andy, a CSS framework would be preferable to a templating framework, mainly for accessibility of the code. Also, much of fannie's "chrome" is pretty much already under a templating framework of our own design. I would have no objections to Bootstrap. If you havent looked at Foundation (http://foundation.zurb.com/docs/), check that out too. I'd say we cant go wrong with either.

Specific UX tweaks (off the top of my head):

• autocomplete for specific form fields - to prevent entering duplicates e.g. vendor = UNIF, unfi, UNFIW, etc.
• form input validation - e.g. price field should know when a user accidentally just scanned a barcode into it.
• status alerts - especially on pages using AJAX e.g. "The Department "Frozen" has been created"
• friendlier navbar, less-finicky about mouse position. Can be tricky on nested flyouts.
• consistent type treatment throughout all UIs + reports
• progress bars where appropriate
• modal popups for quick item maint.
• keyboard shortcuts for repetitive tasks
• switch to jquery datepicker, possibly even moving the calendar plugin options to the datepicker popup.
• overhaul of the entire Fannie design?..... I designed that UI in
• Using a lot of HTML. A lot has changed since then.... If i had to do it all over again it would be edge-to-edge, grid-based, static left-side navbar (optional top-nav), more templated (or even templated. period)

theres certainly more, but thats a good start.

[gohanman]

jquery doesn't have a datepicker AFAIK; jquery-ui does. That change was implemented here: 42dd202c1fdcfd8a97eeb56476fc1fcb3db268c7

I've been playing with modal popups (again with jquery-ui) on the item maintenance page - e.g., to create a new vendor or like code. It is a lot quicker to work with, albeit of course currently inconsistent with everything else.

Vendor & Brand fields do have autocomplete to reduce duplicates. Vendor is a fairly unique case. I want it to be a , eventually, where you have to choose an existing vendor but since it's currently that data's terribly denormalized. What I want for that is really a combobox where it's a text field with a dropdown list that filters as you type. I haven't found an existing implementation that I like though.

Validation would be great. I think we can lean on HTML5's more diverse field types to accomplish a lot of that. It's not true backend validation, just UI hinting, but that's essentially what we're looking for.

Status alerts are really just a subset of the fact that AJAX forms need to be more consistent. Standard message flashing, sure, but also stuff like whether the page reloads on new records, which item is shown after saving, discrepancies between create & update, etc

Foundation looks great, too. If you're already familiar with it, that seems like a decent tie breaker. Re-doing the base templates definitely would be part of implementing the CSS framework. I think the first pass goal should be sort of accents and polish. The basic layout should be similar, fields should be similar, etc. For better or worse, people are familiar with the current Fannie. I think there's going to be some pushback if people can't find an option where they're used to seeing it.

One really simple thing would be to provide a "help" link/button/widget in the default header or footer. FanniePage instances would be responsible for providing help text or a link to an appropriate page in the documentation directory (probably overlayed in a lightbox either way). It would then be easy to auto test which pages have implemented help and have a list of what documentation needs to be written. It wouldn't guarantee that documentation stays up to date, but it would still be a huge step forward.

gohanman commented 10 years ago

I'm going to close #324 but leave a reference to it here. House coupon editor is something that could use [better] documentation, inline help/tooltips, and consistency

gohanman commented 10 years ago

Discussion so far on progress bars #389

gohanman commented 10 years ago

Dayend -> view log should go directly to log Some page should gather all known pages. Sitemap, essentially.

hozt commented 10 years ago

A framework like Bootstrap/Zurb might be overkill for our needs. Both of these do use SASS and either way we should consider have SASS/SCSS versions of the stylesheets available.

For building responsive websites I like the Susy Grid - http://susy.oddbird.net/ grid with breakpoint - http://breakpoint-sass.com/. Both are very easy to use.

It would be great to also come up with a sane way of creating class names. SMACSS - http://smacss.com/book/ is one such method that is being adopted by many.

Here is a great guide on how to format our CSS/SCSS files - http://engineering.appfolio.com/2012/11/16/css-architecture/

gohanman commented 10 years ago

I think overkill is actually kind of the goal. Rather than making it easier to name classes and write (or generate) CSS, let the framework take care of it. Zurb supports SASS & Bootstrap supports LESS if people want to work in something other than vanilla CSS, but I think consistency will be better if developers aren't writing much CSS. Having a framework with pre-existing widgets and styles for everything under the sun makes it less likely someone will need to write custom styles.

That's for Fannie. For the lane a simple grid system and optional SASS/LESS would be more than sufficient. The goal there would really be to produce an identical interface though, just with saner & maintainable styles and nothing inlined as "style" attributes.

jonkeim commented 10 years ago

I'd like to be able to specify search criteria in the Advanced Item Search URL, so that I can send specific searches to other employees. Something like "fannie/item/AdvancedItemSearch.php?brand=ALDEN". (Not that that's the best example since it's easy to recreate, but one could also potentially send much more complex searches...)

gohanman commented 10 years ago

RE: repeatable search: b9f66ef6fb07489563a5750830b65f43861083b9

I haven't rigorously tested if all fields work, but the general concept seems sound. I'm re-populating the form, then re-running the search. The results could theoretically change if the underlying data has changed, but I don't think that's avoidable. IMO re-populating the search form is important so the user has an idea what they're looking at. If they make further modifications and re-run the search, that will be against live data. It'd be confusing if the initial results were from some kind of cache, but then refining the search gave different items because the cached results no longer matched the actual data.

jonkeim commented 10 years ago

I wouldn't worry about reproducing the /exact/ results every time. The criteria is the important bit to me. If I want to send someone a list of "all the Aldens" and an Aldens item has been added to the POS between me sending the URL and the other employee opening it, the right thing to do is include it.

gohanman commented 10 years ago

Great, then it ought to work as is.

On Fri, Aug 22, 2014 at 4:25 PM, jonkeim notifications@github.com wrote:

I wouldn't worry about reproducing the /exact/ results every time. The criteria is the important bit to me. If I want to send someone a list of "all the Aldens" and an Aldens item has been added to the POS between me sending the URL and the other employee opening it, the right thing to do is include it.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/399#issuecomment-53122385.

jonkeim commented 10 years ago

I know you want to keep this thread about Fannie (...should we start a new issue? Or just generally not tackle the lanes yet?), but this one seems dangerous enough to be worth mentioning and/or fast enough to fix: when a register is in training mode, every time a cashier starts a transaction could it give them a prompt something like "You're in training mode and if you don't mean to be here you'll be screwing up your drawer; push [enter] to continue in training mode or [cancel] to exit"?

jonkeim commented 10 years ago

Some minor polish issues in fannie/item/ItemEditorPage.php:

• the (?) tooltip graphics are tabstops, necessitating extra, non-obvious keystrokes while tabbing through the form.
• When changing an item's department, the "Age Req." field doesn't update to reflect the new department's default

gohanman commented 10 years ago

Updates:

I added some default lines to the head of reports as suggested by @flathat (663fb963d7b949284e7d91c55beb3a0c959e4a81). I went with report name, then "Report generated" instead of "As at". I think that's always useful information but still covers the scenario of reporting on the current day. Date or dates are the third line if applicable.

I also put a site map link in the footer and did a bunch of tidying so all page classes have a proper description and nothing throws errors while detecting available pages. I put an "admin" auth requirement on the site map since I haven't yet had a chance to review exactly what it's exposing, but it's an auto-generated list of all known pages.

gohanman commented 9 years ago

This has been hanging out for about a month now. I'd like to settle at least the basic issue of bootstrap/foundation/something else as a UI toolkit. I'd also like to distill down various suggestions into a specific list of bugs, features, and priorities.

I lean towards bootstrap as a toolkit. My own list would be:

• Pare down src/styles.css. Let whichever framework handle the default styling. Tighten up what's left so it applies to specific, well-named classes and not entire elements. The suggested style guide might help there: http://engineering.appfolio.com/2012/11/16/css-architecture/
• Cut down on inline styles. Replace with one of these:
  • An appropriate class from the framework
  • An appropriate class from src/style.css
  • A css_content() method for the page after giving the element a sane ID and/or class
  • A css file for the page after giving the element a sane ID and/or class
  • A store-specific style sheet for that ID and/or class
• Support for a store-specific style sheet
• Consistent icons (and terminology) for create, edit, save, and delete
• Keyboard friendliness. That would include tabstops, keyboard shortcuts, and autofocusing appropriate fields.
• Better notifications on AJAX operations. I don't know if exactly consistent is feasible or not, but at the very least every "save" operation should give a clear notification that it occurred.
• Help as a property of FanniePage. Tooltips are nice, too, but having a higher-level description of what the overall tool does or what the report will show would be good. Attaching it to the class makes auditing progress easier.

By all means add, strike, or change with your own ideas.

jonkeim commented 9 years ago

Choosing Bootstrap sounds fine to me. Not that I have a very informed opinion. No matter what we choose I'm going to have to read up on it. But I guess I should at least log my (sorta lack of) opinion.

gohanman commented 9 years ago

I think learning it should be largely optional. The goal should be that if you write HTML with no styling whatsoever, the framework will take care of making it look nice.

gohanman commented 9 years ago

I started tinkering with a re-writing a page using Bootstrap. The widgets that it provides do look pretty sharp but they're not at all automated. You do have to add appropriate CSS classes to get the desired look and feel. That puts a definite learning curve onto the framework.

One thing that it really hates is Fannie's menu - specifically the left-to-right expansion and the on hover triggers. Even if Bootstrap isn't the right choice, the menu probably ought to change. It's not touch friendly and it's not particularly small-screen friendly either. That doesn't matter now, but mobile accessibility will probably be a request sooner rather than later. To that end, I think the revised UI should have:

• A horizontal menu at the top of the screen
• Menus should open downwards like traditional desktop window menus
• There are no submenus or additional flyouts from within menus

This is not a trivial change, obviously, although I think there's plenty of upside. The issue of whether or not to show menus on a given page goes away. Every (html) page gets the top menu. With only one tier of menus the structure becomes much simpler and the interface for user-configurable menus should become less of a snarled mess. It may be necessary to have more than the current six base menus but I think there's space for a couple more. Visual example:

jonkeim commented 9 years ago

So the new menu buttons only drop down a menu, and are not links in and of themselves? (The obvious problem with on_hover in a touch UI is that it's hard to hover without clicking and navigating away. At least without a fancy active stylus.)

gohanman commented 9 years ago

Well, the buttons open the menu when clicked. You can apply the styling and behavior to a variety of elements including but they cease to function as links. It might be possible to preserve the text as a link with the down arrow icon expanding the menu, but that reintroduces more-or-less the same problem: tiny click targets are not touch friendly.

jonkeim commented 9 years ago

Er, sorry to be unclear. I meant that I am in favor of new buttons that are dropdown-triggers only. (Actually, UI elements that do more than one thing (i.e.: that trigger a fly-out, but are themselves also triggers for unique functionality) are probably not great UI design, even for a traditional desktop interface.)

gohanman commented 9 years ago

Menu option: http://geedmo.github.io/yamm3/

gohanman commented 9 years ago

I'm continuing to update pages and generally getting the hang of using bootstrap. I've got a handful of pages done as well as an editor interface for adjusting the menu (the yamm3 above isn't implemented yet). There's a net-facing copy here if anyone wants a demo to look at. The updated pages are: editing Super/Regular/Sub Departments, Like Codes, Vendors, Purchase Orders, and Store Coupons.

There is one large question about deployment. In my own dev environment, I used Composer to install bootstrap and its dependencies. This is almost certainly the right way to deal with 3rd party components and libraries. However, the recommendation is to leave 3rd party code out of our repo. It is just a recommendation so we certainly could ignore it although I'm inclined on principle to follow best practices. This would end up adding a step to the install process. It would be check out a copy from github, then run "composer update" to install dependencies. Someday it might get back down to a single step along the lines of "composer install corepos/fannie" but that's a longer ways off.

So, thoughts on how the new UI looks/behaves and/or thoughts on dev practices and package management.

joelbrock commented 9 years ago

I do wonder to what extent we'll need to keep the bootstrap dependencies updated. Like maybe, if we want to commit bootstrap to the CORE-POS repo we would only merge boostrap updates while doing a tagged release? Would that mitigate some of the messiness they warn of? I Have already seen some git issues using the giterate submodule, so that also helps to convince me that the Composer route would be the sanest, if not the easiest.

I'm not outright opposed to incorporating Composer into the intial setup flow. I do LOVE the simplicity of the install process currently, but if it is the smarter move overall then OK by me.

gohanman commented 9 years ago

I think in the long run Composer makes more sense than the giterate hack. They've largely solved the same issue pulling updates from a github repo and its more robust than re-inventing it ourselves.

We could keep bootstrap (etc) in the code base and still user Composer for install/updating CORE. It's just bloat in commits and diffs. It would also be easier to do things like upgrade jQuery, test, and rollback to the previous version without any commits or conflicts. Its role would be similar to apt.

On Thu, Oct 9, 2014 at 5:09 PM, joel brock notifications@github.com wrote:

I do wonder to what extent we'll need to keep the bootstrap dependencies updated. Like maybe, if we want to commit bootstrap to the CORE-POS repo we would only merge boostrap updates while doing a tagged release? Would that mitigate some of the messiness they warn of? I Have already seen some git issues using the giterate submodule, so that also helps to convince me that the Composer route would be the sanest, if not the easiest.

I'm not outright opposed to incorporating Composer into the intial setup flow. I do LOVE the simplicity of the install process currently, but if it is the smarter move overall then OK by me.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/399#issuecomment-58585895.

gohanman commented 9 years ago

Update to sitemap so it shows whether or not a page has been updated to the new UI. Intended as kind of a temporary checklist. 34e1c82914f9ce309b798ab3edb877a2cbcbf8e5

gohanman commented 9 years ago

I slightly tweaked the always show menu logic. The menu is always available, but clicking "Fannie IT CORE maintenance & reporting" text toggles it on and off. It defaults to off on extra small screens (defined by bootstrap as < 768px). This is too avoid using vertical space on mobile devices until the menu is actually needed. c0944980960ed9b7a8d458ee8ba3649e50ff459f

Change made for the sake of #418

gohanman commented 9 years ago

Progress & Updates:

• Getting pretty close to every non-plugin page using the new menu.
• Added helper to draw edit/save/delete icons. Centralizing should make future updates easier.
• Added "Help" to the menu. Pages can supply context-specific info about what a particular page does.

gohanman commented 9 years ago

I'm thinking about putting together a release of this soon, or at least a release candidate. I made some adjustments so that composer is supported but not required. I'm undecided whether this is a solution or punting the issue down the road, but it should make the update smoother.

I'm copying the commit comment here since it's a large one that may bog down a browser looking at it: Middle ground on composer & bootstrap. I'm adding a version of bootstrap to the CORE repo. The composer version now installs a parallel copy in fannie/src/javascript/composer-components. Pages will use that version if it is present, but otherwise fail over to the copy I'm committing here. This way developers can experiment with upgrading package versions but end-users don't need to know about it or have an extra step in the install process.

0986c56cf3892fcbd979aeeda6c34e6aa1cd4afb

gohanman commented 9 years ago

Added some notes about using Bootstrap to the documentation. It's by no means comprehensive - just the basic stuff I've used most often to this point. 794040d7b62b16dbc62042b0108ea986eaef5a34

gohanman commented 9 years ago

The release candidate with this is up. RC-1.0.0

gohanman commented 9 years ago

Closing as discussion seems done. Future UI stuff can be posted as bugs (inconsistency can be considered a bug) and/or specific change requests.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[gohanman]

I'm going to close #324 but leave a reference to it here. House coupon editor is something that could use [better] documentation, inline help/tooltips, and consistency

[gohanman]

Discussion so far on progress bars #389

[gohanman]

Dayend -> view log should go directly to log Some page should gather all known pages. Sitemap, essentially.

[hozt]

A framework like Bootstrap/Zurb might be overkill for our needs. Both of these do use SASS and either way we should consider have SASS/SCSS versions of the stylesheets available.

For building responsive websites I like the Susy Grid - http://susy.oddbird.net/ grid with breakpoint - http://breakpoint-sass.com/. Both are very easy to use.

It would be great to also come up with a sane way of creating class names. SMACSS - http://smacss.com/book/ is one such method that is being adopted by many.

Here is a great guide on how to format our CSS/SCSS files - http://engineering.appfolio.com/2012/11/16/css-architecture/

[gohanman]

I think overkill is actually kind of the goal. Rather than making it easier to name classes and write (or generate) CSS, let the framework take care of it. Zurb supports SASS & Bootstrap supports LESS if people want to work in something other than vanilla CSS, but I think consistency will be better if developers aren't writing much CSS. Having a framework with pre-existing widgets and styles for everything under the sun makes it less likely someone will need to write custom styles.

That's for Fannie. For the lane a simple grid system and optional SASS/LESS would be more than sufficient. The goal there would really be to produce an identical interface though, just with saner & maintainable styles and nothing inlined as "style" attributes.

[jonkeim]

I'd like to be able to specify search criteria in the Advanced Item Search URL, so that I can send specific searches to other employees. Something like "fannie/item/AdvancedItemSearch.php?brand=ALDEN". (Not that that's the best example since it's easy to recreate, but one could also potentially send much more complex searches...)

[gohanman]

RE: repeatable search: b9f66ef6fb07489563a5750830b65f43861083b9

I haven't rigorously tested if all fields work, but the general concept seems sound. I'm re-populating the form, then re-running the search. The results could theoretically change if the underlying data has changed, but I don't think that's avoidable. IMO re-populating the search form is important so the user has an idea what they're looking at. If they make further modifications and re-run the search, that will be against live data. It'd be confusing if the initial results were from some kind of cache, but then refining the search gave different items because the cached results no longer matched the actual data.

[jonkeim]

I wouldn't worry about reproducing the /exact/ results every time. The criteria is the important bit to me. If I want to send someone a list of "all the Aldens" and an Aldens item has been added to the POS between me sending the URL and the other employee opening it, the right thing to do is include it.

[gohanman]

Great, then it ought to work as is.

On Fri, Aug 22, 2014 at 4:25 PM, jonkeim notifications@github.com wrote:

I wouldn't worry about reproducing the /exact/ results every time. The criteria is the important bit to me. If I want to send someone a list of "all the Aldens" and an Aldens item has been added to the POS between me sending the URL and the other employee opening it, the right thing to do is include it.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/399#issuecomment-53122385.

[jonkeim]

I know you want to keep this thread about Fannie (...should we start a new issue? Or just generally not tackle the lanes yet?), but this one seems dangerous enough to be worth mentioning and/or fast enough to fix: when a register is in training mode, every time a cashier starts a transaction could it give them a prompt something like "You're in training mode and if you don't mean to be here you'll be screwing up your drawer; push [enter] to continue in training mode or [cancel] to exit"?

[jonkeim]

Some minor polish issues in fannie/item/ItemEditorPage.php:

• the (?) tooltip graphics are tabstops, necessitating extra, non-obvious keystrokes while tabbing through the form.
• When changing an item's department, the "Age Req." field doesn't update to reflect the new department's default

[gohanman]

Updates:

I added some default lines to the head of reports as suggested by @flathat (663fb963d7b949284e7d91c55beb3a0c959e4a81). I went with report name, then "Report generated" instead of "As at". I think that's always useful information but still covers the scenario of reporting on the current day. Date or dates are the third line if applicable.

I also put a site map link in the footer and did a bunch of tidying so all page classes have a proper description and nothing throws errors while detecting available pages. I put an "admin" auth requirement on the site map since I haven't yet had a chance to review exactly what it's exposing, but it's an auto-generated list of all known pages.

[gohanman]

This has been hanging out for about a month now. I'd like to settle at least the basic issue of bootstrap/foundation/something else as a UI toolkit. I'd also like to distill down various suggestions into a specific list of bugs, features, and priorities.

I lean towards bootstrap as a toolkit. My own list would be:

• Pare down src/styles.css. Let whichever framework handle the default styling. Tighten up what's left so it applies to specific, well-named classes and not entire elements. The suggested style guide might help there: http://engineering.appfolio.com/2012/11/16/css-architecture/
• Cut down on inline styles. Replace with one of these:
  • An appropriate class from the framework
  • An appropriate class from src/style.css
  • A css_content() method for the page after giving the element a sane ID and/or class
  • A css file for the page after giving the element a sane ID and/or class
  • A store-specific style sheet for that ID and/or class
• Support for a store-specific style sheet
• Consistent icons (and terminology) for create, edit, save, and delete
• Keyboard friendliness. That would include tabstops, keyboard shortcuts, and autofocusing appropriate fields.
• Better notifications on AJAX operations. I don't know if exactly consistent is feasible or not, but at the very least every "save" operation should give a clear notification that it occurred.
• Help as a property of FanniePage. Tooltips are nice, too, but having a higher-level description of what the overall tool does or what the report will show would be good. Attaching it to the class makes auditing progress easier.

By all means add, strike, or change with your own ideas.

[jonkeim]

Choosing Bootstrap sounds fine to me. Not that I have a very informed opinion. No matter what we choose I'm going to have to read up on it. But I guess I should at least log my (sorta lack of) opinion.

[gohanman]

I think learning it should be largely optional. The goal should be that if you write HTML with no styling whatsoever, the framework will take care of making it look nice.

[gohanman]

I started tinkering with a re-writing a page using Bootstrap. The widgets that it provides do look pretty sharp but they're not at all automated. You do have to add appropriate CSS classes to get the desired look and feel. That puts a definite learning curve onto the framework.

One thing that it really hates is Fannie's menu - specifically the left-to-right expansion and the on hover triggers. Even if Bootstrap isn't the right choice, the menu probably ought to change. It's not touch friendly and it's not particularly small-screen friendly either. That doesn't matter now, but mobile accessibility will probably be a request sooner rather than later. To that end, I think the revised UI should have:

• A horizontal menu at the top of the screen
• Menus should open downwards like traditional desktop window menus
• There are no submenus or additional flyouts from within menus

This is not a trivial change, obviously, although I think there's plenty of upside. The issue of whether or not to show menus on a given page goes away. Every (html) page gets the top menu. With only one tier of menus the structure becomes much simpler and the interface for user-configurable menus should become less of a snarled mess. It may be necessary to have more than the current six base menus but I think there's space for a couple more. Visual example:

[jonkeim]

So the new menu buttons only drop down a menu, and are not links in and of themselves? (The obvious problem with on_hover in a touch UI is that it's hard to hover without clicking and navigating away. At least without a fancy active stylus.)

Well, the buttons open the menu when clicked. You can apply the styling and behavior to a variety of elements including but they cease to function as links. It might be possible to preserve the text as a link with the down arrow icon expanding the menu, but that reintroduces more-or-less the same problem: tiny click targets are not touch friendly.

Er, sorry to be unclear. I meant that I am in favor of new buttons that are dropdown-triggers only. (Actually, UI elements that do more than one thing (i.e.: that trigger a fly-out, but are themselves also triggers for unique functionality) are probably not great UI design, even for a traditional desktop interface.)

[gohanman]

Menu option: http://geedmo.github.io/yamm3/

[gohanman]

I'm continuing to update pages and generally getting the hang of using bootstrap. I've got a handful of pages done as well as an editor interface for adjusting the menu (the yamm3 above isn't implemented yet). There's a net-facing copy here if anyone wants a demo to look at. The updated pages are: editing Super/Regular/Sub Departments, Like Codes, Vendors, Purchase Orders, and Store Coupons.

There is one large question about deployment. In my own dev environment, I used Composer to install bootstrap and its dependencies. This is almost certainly the right way to deal with 3rd party components and libraries. However, the recommendation is to leave 3rd party code out of our repo. It is just a recommendation so we certainly could ignore it although I'm inclined on principle to follow best practices. This would end up adding a step to the install process. It would be check out a copy from github, then run "composer update" to install dependencies. Someday it might get back down to a single step along the lines of "composer install corepos/fannie" but that's a longer ways off.

So, thoughts on how the new UI looks/behaves and/or thoughts on dev practices and package management.

[joelbrock]

I do wonder to what extent we'll need to keep the bootstrap dependencies updated. Like maybe, if we want to commit bootstrap to the CORE-POS repo we would only merge boostrap updates while doing a tagged release? Would that mitigate some of the messiness they warn of? I Have already seen some git issues using the giterate submodule, so that also helps to convince me that the Composer route would be the sanest, if not the easiest.

I'm not outright opposed to incorporating Composer into the intial setup flow. I do LOVE the simplicity of the install process currently, but if it is the smarter move overall then OK by me.

[gohanman]

I think in the long run Composer makes more sense than the giterate hack. They've largely solved the same issue pulling updates from a github repo and its more robust than re-inventing it ourselves.

We could keep bootstrap (etc) in the code base and still user Composer for install/updating CORE. It's just bloat in commits and diffs. It would also be easier to do things like upgrade jQuery, test, and rollback to the previous version without any commits or conflicts. Its role would be similar to apt.

On Thu, Oct 9, 2014 at 5:09 PM, joel brock notifications@github.com wrote:

I do wonder to what extent we'll need to keep the bootstrap dependencies updated. Like maybe, if we want to commit bootstrap to the CORE-POS repo we would only merge boostrap updates while doing a tagged release? Would that mitigate some of the messiness they warn of? I Have already seen some git issues using the giterate submodule, so that also helps to convince me that the Composer route would be the sanest, if not the easiest.

I'm not outright opposed to incorporating Composer into the intial setup flow. I do LOVE the simplicity of the install process currently, but if it is the smarter move overall then OK by me.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/399#issuecomment-58585895.

[gohanman]

Update to sitemap so it shows whether or not a page has been updated to the new UI. Intended as kind of a temporary checklist. 34e1c82914f9ce309b798ab3edb877a2cbcbf8e5

[gohanman]

I slightly tweaked the always show menu logic. The menu is always available, but clicking "Fannie IT CORE maintenance & reporting" text toggles it on and off. It defaults to off on extra small screens (defined by bootstrap as < 768px). This is too avoid using vertical space on mobile devices until the menu is actually needed. c0944980960ed9b7a8d458ee8ba3649e50ff459f

Change made for the sake of #418

[gohanman]

Progress & Updates:

• Getting pretty close to every non-plugin page using the new menu.
• Added helper to draw edit/save/delete icons. Centralizing should make future updates easier.
• Added "Help" to the menu. Pages can supply context-specific info about what a particular page does.

[gohanman]

I'm thinking about putting together a release of this soon, or at least a release candidate. I made some adjustments so that composer is supported but not required. I'm undecided whether this is a solution or punting the issue down the road, but it should make the update smoother.

I'm copying the commit comment here since it's a large one that may bog down a browser looking at it: Middle ground on composer & bootstrap. I'm adding a version of bootstrap to the CORE repo. The composer version now installs a parallel copy in fannie/src/javascript/composer-components. Pages will use that version if it is present, but otherwise fail over to the copy I'm committing here. This way developers can experiment with upgrading package versions but end-users don't need to know about it or have an extra step in the install process.

0986c56cf3892fcbd979aeeda6c34e6aa1cd4afb

[gohanman]

Added some notes about using Bootstrap to the documentation. It's by no means comprehensive - just the basic stuff I've used most often to this point. 794040d7b62b16dbc62042b0108ea986eaef5a34

[gohanman]

The release candidate with this is up. RC-1.0.0

[gohanman]

Closing as discussion seems done. Future UI stuff can be posted as bugs (inconsistency can be considered a bug) and/or specific change requests.