sathomas / stem Goto Github PK

Not really a functional issue, but the dummy URLs used for images in some of the unit tests cause console errors when the unit tests are run in the browser (grunt serve:test). We should replace the dummy image URLs with links to actual images (e.g. a Georgia Tech logo from www.gatech.edu) to eliminate the error messages that may obscure actual errors. Easiest way to see the errors is to look at the console during a unit test.

The current design has focussed on desktop viewports with minimal thought given to smartphones and tablets. It's worth looking closely at the responsive design for these alternate viewports to see what improvements can be made.

Something in the tool chain doesn't seem to be working with the latest phantomjs 2.0 release. Probably ought to fix that to avoid confusion.

I was just messing around with the look and feel on my phone (using the chrome browser) and I came across a bug with the menu. While on the "search the incubator" view I opened the menu and selected one of the menu items to return to the main view. The url updated but the state didn't change and the whole site became unresponsive.

To recreate the issue:

1. on a mobile phone go to stemincubator.org
2. press the magnifying glass search icon
3. After the search page has loaded, press menu on the site's navigation bar
4. Select one of the menu options
5. The site should now be unresponsive

I'm not exactly sure what is happening. The site does actually begin responding again but it becomes very slow and almost impossible to use.

Once the site is launched, demographic data (or requests/complaints) about our users may suggest we rethink the decision not to support IE9. In preparation for that possibility, we should map out a plan for supporting IE9. Two known issues are #29 and #31, though there may be others.

1. Thorough test with IE9 to look for other potential problems.
2. Provide CSS fallback styles for non flexbox support (e.g. resurrect #31).
3. Propose and test solutions for CORS workarounds (e.g. resurrect #29).
4. Propose and test solutions for other problems uncovered in step 1.

Clicking on administrators targets URL #schools. Should this be #administrators?

Index.html Line 144

In addition to the current styles for buttons,

we also need outline styles, e.g.

background-color: transparent;
border-width: 2px;
color: @color-theme;

Documentation and style guide should be updated appropriately.

The initial styles make fairly heavy use of flexbox layouts for the grid and for the discovery navigation panel. To support IE9, we'll need fallback style rules that don't rely on flexbox. Depending on their complexity, they may need to be incorporated into separate style blocks based on modernizr classes instead of the standard CSS fallback approach. This is especially likely given that the (to be developed) tablet-sized styles are probably going to mess around with flexbox ordering. Best guess is that plain old float styles should work for the grid, but the discovery navigation might require display:table. It's not essential that the discovery navigation fallbacks are faithful reproductions of the current styles; they only have to provide a reasonable user experience. In addition to the comments within the style sheets, the live style guide for the site may be helpful in explaining how the current styling works.

Current the high level views (adminsAsDiscovery, discoveryAsContent, partnersAsDiscovery, posAsMap, teachersAsDiscovery, and teacherSearchAsPage) lack unit tests. We should add unit tests for those views.

There is a report (unconfirmed) that IE9 is not able to retrieve data from the OAE's REST API, though it apparently has no problem with DonorsChoose. Needs investigation to see if this is true and, if so, what fixes are available. Note that DonorsChoose uses JSONP while the OAE is pure REST JSON. Also, the OAE API implements CORS; it's not clear how well IE9 deals with CORS.

Even though we've got 100% code coverage, the unit tests for the high level models, e.g. partners and teacherSearch, aren't currently testing a lot of the models' functionality. Additional unit tests should be added to better validate the model code.

Is it ok to create new branches to target each of the issues?