Scout - Web Application User Roles and Features Update Wireframes Challenge

Welcome to Scout - Web Application User Roles and Features Update Wireframes Challenge!

We need you to come up with a wireframes solution - using Axure - that covers the requirements of a workflow-based application (web) for the Department of Energy Building Technologies Office (BTO) Scout tool, which estimates the energy conservation potential of new building technologies on a national scale.

We developed a first version of this application and now need to perform some updates to the application’s overall workflow.

Best of luck!

Round 1

2. End-to-end Analysis (screens below)
2.1.1. Adding and/or Editing Custom ECMs
2.1.2. Running an Analysis
2.1.3. Viewing Results from Past Analyses
2.1.6. Viewing ECMs from Past Analyses
2.1.7. Start New Analyses from Past Analyses as a Reference
2.2.1. Viewing ECM(s) Previously Submitted for Review
2.3. ECM Notifications Workflow

3. Improvements
3.1. Add ECM Form
3.2. Baseline Calculator
3.3. ECM Summaries Page

Round 2

1. Authentication

2. End-to-end Analysis
2.1.1. Adding and/or Editing Custom ECMs
2.1.2. Running an Analysis
2.1.3. Viewing Results from Past Analyses
2.1.4. Deleting Past Analyses
2.1.5. Downloading Analysis Results
2.1.6. Viewing ECMs from Past Analyses
2.1.7. Start New Analyses from Past Analyses as a Reference
2.2.1. Viewing ECM(s) Previously Submitted for Review
2.2.2. Manage User Account
2.3. ECM Notifications Workflow

3. Improvements
3.1. Add ECM Form
3.2. Baseline Calculator
3.3. ECM Summaries Page

 

The goal of this challenge is to create clickable wireframes to create an intuitive and well-designed user interface. You are provided with the existing interface design/version, requirements, and stories for updating the existing interface with the new wireframes.

Background
The Department of Energy’s Building Technologies Office (BTO) is developing a modeling system called “Scout” that will help measure the energy conservation potential of new technologies on a national scale. BTO calls these new technologies “energy conservation measures” (abbreviated as ECMs).

The existing app - http://scout.energy.gov - improves the user-friendliness of several key Scout features; for example, it allows one to easily estimate the total segment of U.S. building energy use and CO2 emissions that a candidate technology might affect; to rapidly create new Scout energy conservation measure (ECM) definitions and send them to BTO for review; and to interactively visualize energy use, cost, and CO2 emissions results for ECM portfolio simulation runs.

 

The app’s capabilities improve the accessibility of Scout data and results and might expand the base of users that wish to contribute new Scout ECM definitions or run custom Scout analyses. Looking ahead, further enhancements to the app will continue to improve the tool’s potential for broader impacts across the building simulation community.

The goals for this wireframe exercise are to:

1. Enable end-to-end Scout analyses within the app.

2. Add user accounts to support saving custom ECMs and analysis results.
3. Update existing app components to reflect new Scout features.

 

User Roles

We will add user accounts to the app: member (regular user) and manager.

 

These accounts allow users to save custom ECM definitions and analysis results in their profile. In integrating with the end-to-end analysis capabilities, users should also be able to select a subset of both their own ECMs and the default ECMs provided on the site to include in a given analysis, save and recall past analysis results, and recall or be able to identify the ECMs associated with any particular result.

 

This table showcases the features and permissions associated to each user role we want to see within the application; blue denotes features that are included for a user type and gray denotes features not explicitly blocked, but also not necessarily meaningful for a user type.

 

General Requirements

• Produce HTML click through wireframes that can be used to demonstrate all mentioned functionalities as required in each round.

• The website must be very easy to use and intuitive. Keep that in mind when designing your solution.

• You MUST cover all use cases mentioned in screens requirements below and user roles above.

• You MUST use wireframes note pane in every single page you design to explain what cases/items are addressed in that page and what things you added/changed/removed.  Use the note pane to make your idea clear and help the client give you constructive feedback.
   

Screens Requirements
Overall

• Keep consistency with the existing header and footer (with wireframes visual style).

• You do not need to re-do the whole UI to showcase the new features. You can use screenshots or simply placeholders to substitute sample data or components from the existing app that won’t be affected by your changes to speed up your work.

• Solutions that incorporate the required new features with minimal disruption to the existing UI are encouraged.

 

1. Authentication

• Create a login page that asks for email, password and the following features:

  • Permanent or time-delayed account lockout after N login attempts.

  • Cannot inform users of the case when a username is valid but the password provided does not match (can provide a general message like “invalid username or password”).

  • Cannot inform users creating new accounts if a username has been taken.

  • Captcha or other rate limitation mechanism for new account creation.

  • Appropriate security protections and workflow for password reset

  • Enforced password complexity requirements

  • Support for Google Sign-in.

• Create a registration page that allows new users sign up. It should request the following fields:

  • Email.

  • Password.

  • Confirm password.

  • Remember password checkbox.

• Depending on the logged in role, user would land in a specific environment;  the current overall navigation system of the existing application must be extended to allow new pages to be allocated for manager-specific tasks/reports.
  
   

2. End-to-end Analysis

We need to add the ability for users to run Scout on a set of custom ECMs (developed via the web app or locally on their computers) and view the results. The existing website has the infrastructure to create (but not store) ECM definitions (ECM Summaries page > Add New ECM) and view the results from the Scout analysis engine, but the intermediate steps currently require running the analysis engine manually on one’s own computer through a console (FYI running python scripts).

 

We need to rethink the UX to create the end-to-end analysis workflow and make it available for the user in an easy way. The existing workflow can be modified in other ways (e.g., changing input file locations, suppressing or revising console outputs) to be amenable to the web app environment.

 

2.1. Member User Analysis Workflow

In each of the use cases/workflows described below, assume the user is signed into their account when they begin. (If the user is not signed in, features that require a user account should probably be hidden or disabled.)

 

2.1.1. Adding and/or Editing Custom ECMs

• On the ECM Summaries page, the user drags and drops one or more ECM JSON file(s) from their local filesystem onto the page to add those ECMs to the list. Dragging-and-dropping ECMs should automatically switch the toggle and put the user in the “Custom ECMs” mode.

• Each of the uploaded ECM JSONs is automatically processed by a script in the background, which yields a result for the ECM that should be automatically loaded into the app in the background. While an  ECM is being processed, a row should show up for the ECM in the summary list that includes the text “Preparing [ECM NAME]...” with a waiting icon or progress bar next to it, and locks the dropdown arrow that is clicked for further ECM details..,

  • The progress of all background processing of newly added ECMs should be included in a consolidated status indication somewhere near the top of all screens (e.g., in the top navbar).

  • This status indication should show at a glance (i.e., without clicking or mouseover), at a minimum, that background processes are running (including text like “Preparing ECMs…”. The number of queued actions could also be included. Clicking the status indication area should open an overlay that includes a list with the active and all queued background processes, along with the option to cancel any queued actions.

    • Should a user cancel any of the queued actions, a “restart” icon (e.g., like this) should appear next to the list item, allowing them to re-initiate this action.

    • Additionally, should any of the background processes fail, an appropriate icon should appear next to the failed list item and in the overall status indication (e.g., red exclamation point)

• If the ECM preparation background process fails on a certain ECM, some sort of error icon appears in the ECM’s row in the summary list and clicking the arrow to expand that ECM should reveal an error message indicating why the ECM definition is invalid. Example error messages (output from the underlying Python code) include:

  • "Invalid performance or cost units" or

  • "No data retrieved for applicable baseline market definition".

• Alternatively, if a user clicks ‘Write New ECM,’ they can create an ECM from scratch using the existing Add New ECM web form. Here, the Generate ECM button at the end of the web form should trigger the background preparation process for that new ECM, and the output data for the new ECM should be added to the existing ‘Custom’ list of ECMs for the user on the ECM Summaries page.

• If a user edits any ECM in the ‘Custom’ list via the web form and clicks ‘Generate ECM,’ those edits trigger the background preparation process for that edited ECM, and the updated output data for the ECM should be reflected in the ‘Custom’ list of ECMs for the user on the ECM Summaries page.

• Users should not be able to delete the default ECMs from their list, even in the “Custom ECMs” mode. Editing default ECMs should create a duplicated ECM with a different name. User-specific custom ECMs should not be deleted but rather archived such that if a user later wants to recall the ECMs used in a previously run analysis, any ECMs that were archived can be restored to the list (see Viewing ECMs from Past Analyses).

 

2.1.2. Running an Analysis

• On the ECM Summaries page, users begin by switching to “Custom ECMs” mode, which should then show checkboxes for each row in the combined list of default and user-specific custom ECMs and ECM packages along the left side of the list. These checkboxes enable them to select the ECMs for a new analysis.

• Once they have finished selecting the ECMs they want to include, they click a button to start a new analysis with the selected ECMs that opens an overlay prompting them to provide a name for the analysis. (There should also be an option to clear the ECM selection checkboxes if the user decides they don’t want to run an analysis.) Clicking OK in that overlay starts the analysis. Clicking cancel or clicking away from the overlay should close the overlay but not clear the user’s ECM selections.

• As described in the section “Adding and/or Editing Custom ECMs”, while an analysis is running, a progress bar or other status indication should be shown somewhere near the top of all pages (likely somewhere in the top navbar), such that a user may continue browsing pages as the analysis is running in the background. Clicking on that status indication should open an overlay or some mechanic that shows all processes running in the background.

• When the analysis is complete, the user should get a notification indicating as such. Switching to the Analysis Results page, clicking the Custom Results toggle should open an overlay (or some other mechanic - open to suggestions) that allows the user to select from a list of results by name and run date/time. Actively running analyses not yet available should appear in the list but with a progress bar or some indication that the analysis is still running. Selecting a particular set of results should then cause them to be shown in the available visualizations.

  • Within the overlay or whatever mechanic is used for analysis selection, users should also be able to rename completed analyses.

 

2.1.3. Viewing Results from Past Analyses

• Users should be able to switch between analysis results by clicking wherever the mechanic is that brings up the list of available analyses. The results currently shown should be indicated with a highlight, icon, or other method that is UX/accessibility appropriate. Clicking on another result in the list should switch the visualizations to those results.

 

2.1.4. Deleting Past Analyses

• From the list of available analyses on the Analysis Results page after selecting the Custom Results toggle, there should be an option in each row to delete existing analyses from the list with a small delete button or X icon. Users should be prompted to confirm deletion before the results are removed.

• Deletion of an analysis result should not cause the ECMs included in that analysis to be deleted.

 

2.1.5. Downloading Analysis Results

• From the list of available analyses, there should be a button or icon to download 1) the summary Excel or CSV file(s) or 2) ecm_results.json (a master results JSON file).

 

2.1.6. Viewing ECMs from Past Analyses

• Using the same mechanic used on the Analysis Results page to bring up a list of and select stored analyses, users should be able to open the list of stored analyses on the ECM Summaries page when in Custom ECM mode.

• Selecting a past analysis from the list will cause the ECMs on the page used in that analysis to be selected.

• Any ECMs that were archived should be restored to the list with some indication that they were archived (perhaps with a different ECM name font face, different background color for the row in the list, or some other approach), including a button/clickable icon in place of the “archive/delete” icon that allows users to restore ECMs to the active custom list.

• ECMs that are running but not yet complete should still offer the ability to see the ECMs that were included in the analysis on the ECM Summaries page with the aforementioned functionality.

 

2.1.7. Start New Analyses from Past Analyses as a Reference

• Following from the workflow to view ECMs included in past analyses, if users wish to run another analysis with a similar list of ECMs, they can select the analysis in question from the overlay or whatever mechanic is used for selecting analyses, which will then update the list of ECMs to select the checkboxes for those ECMs that were included in the selected analysis.

• The user can then make changes by selecting or deselecting additional ECMs before following the workflow above “Running an Analysis” to start a new analysis.

 

2.2. Manager User ECM Review Workflow

2.2.1. Viewing ECM(s) for Submitted for Review

• When users submit ECMs for review, they should be automatically routed to the manager associated with the applicable end use for the ECM.

• From the ECM Summaries page, managers should have a button that they can click to switch to “management mode.” Clicking that button switches the ECM list to the list of ECMs available for review. The ECMs in management mode should behave in the same way as in the standard list. Clicking the edit button should open an overlay allowing the manager to review the ECM in detail; clicking the arrow to expand the ECM reveals a figure showing energy, CO2, and cost savings over time.

• From this view, managers should additionally be able to perform review actions. Clicking the review button next to an ECM opens an overlay with these functions:

  • “Accept” adds the ECM to the default list of ECMs for all users. The manager should be able to edit the ECM and save their changes before accepting the modified ECM.

  • “Decline” returns the ECM to the submitting user with an optional note to include in their notifications from the manager regarding why the ECM was declined. Users can re-submit an ECM with changes.

  • “Silence” takes no action on the ECM but discontinues any notification regarding review requirements and moves the ECM to the bottom of their queue (if applicable). ECMs that have been silenced could be hidden or collapsed.

 

2.2.2. Manage User Accounts

• Manager users can be associated with one or more ECM end uses, such that when a new ECM is submitted for review, managers who have been linked to that end use are notified that a new ECM is awaiting their review. A new screen/view/page is needed that enables managers to select the end uses that should be linked to their account or other manager accounts.

• To avoid confusion, only one manager should be able to be assigned to each end use.

• Manager users can administer other user accounts. A screen/view/page should be available to manager users that allows them to elevate/demote member users to/from the manager role, and suspend and reactivate member users.

 

2.3. ECM Notifications Workflow

• We’d like to change the ECM submission process such that the ECMs submitted by users are “routed” within the app to manager users who can review the ECM, return it to the submitting user with comments or clarifying questions, add it to the portfolio of default ECMs available to all users on the app, or decline to include it (effectively no action). These ECM submission review features would only be available to manager-level (and above) accounts.

• Incorporate a notifications feature to notify users of completed analysis results available for visualization (specific text would be something like “Analysis [ANALYSIS NAME] has completed.” The same notifications mechanic could also be used to notify manager-level users that an ECM is awaiting their review.

3. Improvements

We need to update the UI to adopt certain features and showcase slight modifications.

 

3.1. Add ECM Form

• We have added a time-sensitive valuation parameter to ECM definitions, which allows users to specify whether an ECM has a time-varying effect on energy use, e.g., by shifting load from peak to off-peak hours of the day. The ECM definition form should be updated to include this parameter as an optional selection by the user.

• Specifically, this requires that a field be added in step 7 (optional parameters) in the “Add New ECM” form. Refer to the details about how this parameter is implemented (here) in developing the specific field characteristics for this parameter in step 7. All types of time-sensitive ECM features should be handled (e.g., “conventional,” “shave,” “fill,” “shift,” and “shape” as described in the linked documentation).

 

3.2. Baseline Calculator

• Improve workflow clarity on baseline calculator to make clear that users have to click away from end use dropdown for further selections (currently they are hidden by the end use dropdown in step 4) or change the functionality or layout to make further selections visible while user is still in the end use dropdown. (See illustrative screenshots and explanatory captions below.)

• Support switching the baseline calculator between AEO years (switching the data JSON and calculator option configuration from CalculatorService.js). Add an AEO years dropdown on top of the calculator box alongside some an explanatory text (2–4 lines).

• The user has made their selections in the end use dropdown and they need to make further selections, but they can’t see that because the dropdown menu obscures the entire area below. The user must click away from the dropdown or click the open/close dropdown arrow to get it to close so that they can proceed. See screenshot.

• These further selections are what await the user that has made the selections shown in the previous screenshot, but that might not be obvious to them since they can’t see that these fields have appeared under the dropdown menu. See screenshot.

3.3. ECM Summaries Page

• Add export option for visualizations in PDF, SVG, CSV and PNG format. Probably as a dropdown option in each visualization/chart of the site.

• Add a “Download All ECMs” function on the ECM Summaries page.

• Add progress bar or other progress indication for custom data uploads and when the main visualizations on “Analysis Results” page are loading, in place of the spinning icons.

 

Screen Specifications

Desktop: 1280 pixel width. Height determined by content length.

 

Target User

- Technology and program managers within BTO (Building Technologies Office).

- DOE (Department of Energy) offices.

- Federal agencies.

- External BTO partners (e.g., universities, national labs, industry organizations).
 

Judging Criteria

- User experience.
- Completeness and accuracy of the areas of functionality and content.
- How well your wireframes provide a consistent user flow and clear information architecture for the application.

Submission & Source Files
Preview Image

Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.

Submission File

All requested contest requirements/screens as clickable HTML files.

Source Files

Wireframes should be built in Axure. The resulting files should have generated HTML files. Also, all the content must be listed and the pages are linked together to show page flow.

Final Fixes

As part of the Final Fix phase, you may be asked to remove, update, or change some features of the wireframe.