Prototyping Parallax IDE (Multiple Elements)

[jimjeffers]

[UPDATE: This discussion began as Project/File UI design but various issues pushed us to consider many other factors simultaneously. Once design of certain elements is deemed final, separate issues will be created to house each element individually]

Here are some notes from our initial discussion on file navigation:

File Navigation

Let’s create a list of common scenarios:

1. New Project (No files)
2. Minimal project (1 file)
3. Sandbox project (multiple independent files)
4. Complex project (multiple files w/ entry point)

Questions to ask ourselves:

What’s good and bad about the way we’ve done things in the past?

People are struggling with how to add updated files for a given library… They include libraries inappropriately.

The names are different on every platform.. C drive on windows.. you don’t see the drive name but you see the user folder on mac/linux (mobile). Some platforms hide the nature of the storage of the medium. You don’t know where it is.. kind of like iCloud / cloud storage.

Simplify the way we manage files (hide the storage medium) but retain the ability to create sub directories within the project.

Most of the time our projects are stored in a given folder. Some files in addition to the executable source code.

Project selection — then project directory specific file system. Have the ability to export/import source for personal backups / sharing with others.

We do have a need to allow you to open up or view files from other projects.

• Challenge: Open files from other projects — jump between projects. We can’t have multiple projects open at once like we do in common IDEs as the ChromeOS or web app will only allow one project at a time.
• Fast project switching.. how will we tackle that?
• Perhaps we move to an autosave sort of platform.
• No version control at this point.. maybe down the road. Eventually we’d like every file to have it’s own history. A little database of revisions.
• Keep in mind we may be adding version control sounds
• Simplicity with flexibility. Obfuscate any complexity from the user under the hood.
• Some people are such bad housekeepers at managing their files that they trip over things.
• With parallax we hope that we can prevent folks from making their own file system mistakes such as:

1. Making backups of source code in whatever way that they want.
2. Make copies of file.. Program1.txt, Program2.txt, Program2_final.txt, etc..

• The file is it’s own entity. We want the user to never feel they need to make a backup of it. Whenever you refer to the system.
• Ultimately we want to make it so that every file has a unique ID.. with an alias. The system would manage the file itself.
• Fuzzy text search for file name.
• There are no objects or classes in the current iteration but there are routines you could call.

What needs are different from the user’s of the parallax IDE?

How might we handle this design challenge on a small screen vs. a large screen?

• More automatic storage.
• removing some of the file system complexities.
• Hide the difference across platforms.
• We need to keep it familiar across platforms.

1. Address file drawer.
2. Project switching.
3. Directory creation.
4. File creation.
5. Moving file / renaming.
6. Deleting a file.
7. Mobile first.

In the Future:
8. Dependency Management.

Self managed — including a library. Third party and parallax based. Can we automate this process?

Stay away from dropping zip files onto the file drawer.

Version conflicts — automatic repository system. Has to retain a database of sorts so that this file is referenced (i.e. Gemfile or Podfile)

Send examples on Cocoapods, NPM, RubyGems.

[jimjeffers]

Notes from our continued discussion:

[This discussion generated the first File Navigation mock-up screencast and pdf]

App Menu

• Editing Items
• Provide the right option at the right time — in the right context.
• See the scratchpad/workspace for menu design document

Profile

• Login/logout
• Create a wireframe that shows.

New Menu

• New button should provide access to both files and folders.
• Files are priority.
• Look into android design guidelines on section headers providing interactive elements.
• Research examples of new item menus using section headers to create.
• Checkout Issue UI Icons #319 from Inbox https://www.google.com/inbox/ to see some interface examples.

More Button

• For specific files.
• Make tablet mockup of file navigator.
• As long as touch is available show the tablet style navigator.
• If all else fails all desktop class devices will get the touch interface.

Fuzzy Search

Project level and global level prioritized results.

Xcode / Browser Style

• Back and forward button.
• User will need to know what project / and file they are currently in when they switch between files.

Common Actions

What are the primary actions our users need to use most frequently?

[Update: See newer post for updates to this subtopic]

Let’s create a list:

1. < text editing functions >
1. Run (Compile / Download)
1. Check Syntax (Compile)
1. Save
1. Identify
1. Memory Map…

Can we prioritize them?

Coding Pane

What are some common items expressed in code that we could automate or simplify for our user?

1. Linking files?
2. Declaring the stamp type?

Questions to ask ourselves (reiterate from file navigation):

What’s good and bad about the way we’ve done things in the past?

What needs are different from the user’s of the parallax IDE?

How might we handle this design challenge on a small screen vs. a large screen?

[PropGit]

Icons post moved to separate issue

[jimjeffers]

@PropGit Notes from our discussion today related to mockup Screencast and PDF:

Project Drawer

• Jeff to add Parallax IDE logo to google drive. Done.
• Jim to replace user profile pic with IDE logo. Jeff provided graphics here. Font for "Parallax IDE" title is Orbitron Medium. Done
• Jeff still considering floating toolbar possibly remove nav bar item if wee stick with it. Done.

Fuzzy Search

• Jim to clarify that the fuzzy search results are in fact scrollable. Add more items to the results to show this. Done
• Add a bolding or highlighting to the matching characters. Done
• Project and filename for now… maybe folder.. the priorities need to be clarified. Jim to mockup fuzzy search results with files, projects, and folders. Done
• Possibly differentiate projects with colored icons.

Editor View Title Bar

• Editor view.. show the project and directory as we do on search results in the navigation bar.
• Search results ./ nav bar. Show the context above or below the filename? Jeff likes above.

FAB and Context Switching

• One more version of editor toolbar with stickersheet.
• Check syntax should jump to the offending code and give an error message.
• Fine tune the debounce for how often we compile code in the background.
• Download and memory map — cannot do when the syntax is bad. Also — identify.
• Debug, Save, Identify need to work in both situations..
• Identify connects to a micro controller and shows ports etc.. Jeff to provide existing UI for identify from prior IDEs. Done.

On Screen Keyboard and UI?

• iOS accessory view floating on top of keyboard.
• What should happen to the FAB when the onscreen keyboard sows up?

More Button

Revise menu — it should be:

1. Stamp
2. Language (Syntax)
3. Settings (is this specific to file or app?) Jeff was thinking of app. Jim was file.

Find Replace..

Need a mock up for the find and replace UI.

Close button?

We may still need it. Explicit or implicit? Tabs or no tabs? That is the question.

Tabs?

Mockup or show example of tabs.

Project Settings

What do we put in the project settings?

Undo/Redo

We need to add this to the editor UI.

Help button

• Could be put on the project drawer.
• Can put on the context view as well — jump to specific language.

File Cut / Copy / Paste

Secondary toolbar on desktop/mobile.

Save as / Print

Put these in context menu for specific file.

[PropGit]

Updates from Jeff:

Fuzzy Search

• Project and filename for now… maybe folder.. the priorities need to be clarified. Jim to mockup fuzzy search results with files, projects, and folders.

• Results to contain Filename (if matching) in large black font, then below, Project > Folder in small grey font. If it's a Project or Folder that matches (instead of Filename), then result contains "..." in small black font (representing possibly multiple files), then below, Project > Folder in large grey font.
  • Search result priorities are
    • Filename (within current project)
    • Filename (within other projects)
    • Projects
    • Folders (within current project)

Editor View Title Bar

• Search results ./ nav bar. Show the context above or below the filename? Jeff likes above.

• We should remain consistent. Let's try Filename (above) and Project > Folder (below, in smaller font of fainter color) like in search results.

More Button

Revise menu — it should be:

1. Stamp
2. Language (Syntax)
3. Settings (is this specific to file or app?) Jeff was thinking of app. Jim was file.

• If app settings are available through another means, this menu item begs for a different name. I'm unclear what file settings it would give access to: file name (for renaming?), Save As?, Duplicate?, Delete?, Print?

[PropGit]

Updated from Jeff:

Floating Toolbar

The floating toolbar concept seems very practical for the Project Files View, but unfortunately less practical on the Editor view. I'll explain:

• On the Project Files View
  • There's less opportunity for the keyboard overlay to consume the bottom of the screen
  • It displays the most-likely needed options (create folder / create project) immediately, still allowing simple access to existing folders and files
  • It collapses to a smaller icon when scrolling
  • NOTE: We'd want to ensure that the scrollable area allows for scrolling the last item all the way above the smaller icon so there's no chance of unavoidable obscuring of a folder or file name.
• On the Editor View
  • Without a hardware keyboard, there's ample time that the keyboard overlay will consume the bottom of the screen
  • Very frequently used operations are two taps away (instead of one tap) always
  • It's always cover some text of the editor's source code (we'd have to allow for scrolling the last line above the smaller icon
  • Examples like Gmail (mobile) only use the floating button in views where you're not editing (an email, in this case)... so it's not obscuring anything.

I noticed on my Gmail (see screenshot) that there's four buttons plus text on the toolbar; the left arrow (left side), text of operation, then two function buttons followed by a more button that gives access to extended contextual menu items. I think we'd be well off to design with this in mind, where we have two most commonly used functions just one-click-away, and others in the more menu.

I still like the idea of the background compile / warning system. Maybe we can transform the more menu into a bright exclamation point at those moments and hide the functions of the context menu (and toolbar) that are not possible without compilable code at that moment, only to reveal those items again once the code is sound.

Another thought is to have the more button expand leftward across the toolbar (covering the source title and left arrow buttons temporarily) with icons for the context menu items.

With these changes (or similar ideas I haven't thought of), perhaps the editor view is never obscured by anything other than the possible keyboard overlay in this case.

[jimjeffers]

Hey Jeff,

I did more research and your points are indeed valid on the FAB. I think it works on the project views but is a bad fit for the editor view especially due to the presence of the on screen keyboard. I see two options — we can use a softwindow mode (or since this is a web app some javascript to replicate softwindow mode. This option would allow us to have a toolbar that floats above the keyboard as the user types. OR we just stick to the gmail approach and provide two primary options and a more button.

I advise against:

Breaking too many design patterns:

1. Changing the icon of the more menu.
2. Changing the type of menu transition for the more menu to something custom.

I recommend keeping those standard to maintain familiarity and predictability with the OS on android and chrome.

I’ll provide mockups of both solutions.

• Jim

On Nov 30, 2015, at 12:36 PM, Parallax Git Administrator notifications@github.com wrote:

Updated from Jeff:

Floating Toolbar

The floating toolbar concept seems very practical for the Project Files View, but unfortunately less practical on the Editor view. I'll explain:

On the Project Files View
There's less opportunity for the keyboard overlay to consume the bottom of the screen
It displays the most-likely needed options (create folder / create project) immediately, still allowing simple access to existing folders and files
It collapses to a smaller icon when scrolling
NOTE: We'd want to ensure that the scrollable area allows for scrolling the last item all the way above the smaller icon so there's no chance of unavoidable obscuring of a folder or file name.
On the Editor View
Without a hardware keyboard, there's ample time that the keyboard overlay will consume the bottom of the screen
Very frequently used operations are two taps away (instead of one tap) always
It's always cover some text of the editor's source code (we'd have to allow for scrolling the last line above the smaller icon
Examples like Gmail (mobile) only use the floating button in views where you're not editing (an email, in this case)... so it's not obscuring anything.
I noticed on my Gmail (see screenshot) that there's four buttons plus text on the toolbar; the left arrow (left side), text of operation, then two function buttons followed by a more button that gives access to extended contextual menu items. I think we'd be well off to design with this in mind, where we have two most commonly used functions just one-click-away, and others in the more menu.

https://cloud.githubusercontent.com/assets/1266318/11483745/0524a04e-975f-11e5-9272-9eb1c4fa2380.png
I still like the idea of the background compile / warning system. Maybe we can transform the more menu into a bright exclamation point at those moments and hide the functions of the context menu (and toolbar) that are not possible without compilable code at that moment, only to reveal those items again once the code is sound.

Another thought is to have the more button expand leftward across the toolbar (covering the source title and left arrow buttons temporarily) with icons for the context menu items.

With these changes (or similar ideas I haven't thought of), perhaps the editor view is never obscured by anything other than the possible keyboard overlay in this case.

—
Reply to this email directly or view it on GitHub #318 (comment).

[PropGit]

Hi @jimjeffers

Good points. I'm pondering this more. Maybe changing the more menu icon is not the right perspective; perhaps it's more that we're replacing it in certain contexts, the there can be an animated (circular) animation to call attention to the transition from a more menu to an error notification. When pressed, the error notification displays the error toast and navigates to and highlights the offending source. When the source is repaired, the notification icon transitions (animates) to a more button again.

Note:

• I found a case where a material-based toolbar button is animated in the Sunrise app.
• Also the Gmail app's Compose view (in above post) has two expanding more-like buttons; the more button and the attach (paperclip) button both present a drop-down menu. Maybe we'll find that as a possible solution for our tight-space dilemma.

[jimjeffers]

@PropGit given that we won't be able to make much use of suggestions (per the fact that our users will be typing code) I think we may have more usable space by creating a custom accessory view to float above the keyboard or rest at the bottom of the editing view when the keyboard is not visible. We could still definitely do a dual dropdown menu as discussed. I'm open to discussing further. Please checkout the latest round of revisions I mocked up today and let me know when you'd like to get together to discuss!

Screencast:
https://drive.google.com/file/d/0B53rXRf-3dMiRmJmckZIa0pFZms/view?usp=sharing

PDF:
https://drive.google.com/file/d/0B53rXRf-3dMiSHE0UDNHOEJONkk/view?usp=sharing

[jimjeffers]

@PropGit Sorry correct link to the PDF is:
https://drive.google.com/file/d/0B53rXRf-3dMiSHE0UDNHOEJONkk/view?usp=sharing

[PropGit]

@jimjeffers Thanks Jim. Yes, it was good for you to apply the remaining time to the mobile design- I agree.

Project's Drawer

• Header
  • The addition of the logo and title+font look great! The "PARALLAX" text should say "PARALLAX IDE" however, so it appears you'll have to make the logo size and font size a little smaller to fit it in nicely.
• Project Files View
  • I'd like to call this simply "File View" from now on
  • Thanks for including the modified indicator. I think we should make the color a shade of red to give it more of a warning kind of feel
• Search
  • Excellent! Looks great.

Editor View

• Line wrapping - that is not practical for source code (unless we can find a better way to do it). One big problem is that line wrapping obscures indention. Unless a better line-wrap solution is devised, we've settled on the need to scroll left/right and being able to zoom in/out with pinch-to-zoom gestures
• Source Title
  • You said it's breaking convention, but I think this is a well-justified place to do so
  • Yes, long filename should be truncated as "MagicBoard_Te..."
  • Yes, long project path can be "MagicBoard > ... > Examples" or "MagicBoard > ... > Examp..." or even "MagicBoa... > ... > Examples" depending on length of overall, project name and current folder name
• Play Button - Thanks, this improves things quite a bit
  • This and the Download item in the More menu are the same thing; should be same icon.
    • We traditionally use a play button for this "download/run" function
• Keyboard Accessory Tray
  • I like undo/redo and save there
  • I need to consider the close, validation and grouping idea more
  • Having Find/Replace there could definitely be a bonus also
  • I like how it will still be visible when the keyboard is hidden
  • If we employ this feature, does that still work with custom keyboards like Swype?
  • What do you think would happen on iOS?
• Source Tabs
  • I like it a lot, but I really want it to collapse into the top toolbar somehow to save vertical space when not needed.
    • Perhaps a very small down arrow (looks like a "v") at the bottom of the top toolbar (and horizontally centered) to indicate they can grab and drag it down. Then, the opposite indicate, but on the Source Tabs toolbar indicating it can be slid up, but also scrolling the actual source in the editor will cause the Source Tab to slide up out of the way too.
  • The modified indicators are very important here. Thanks!
• More Menu
  • I like the layout
  • Great choice in icon or Stamp and Syntax
    • Remember, "Syntax" is really supposed to be "Language"
  • I like the icon you chose for Syntax, but with it being "Language" I'm not sure it fits anymore
  • I begrudgingly agree about hiding menu items from the more menu in different contexts... disabling them will maintain the sight-knowledge for the user

[jimjeffers]

Header
The addition of the logo and title+font look great! The "PARALLAX" text should say "PARALLAX IDE" however, so it appears you'll have to make the logo size and font size a little smaller to fit it in nicely.

Aha! Ok I was afraid of that :) I'll finesse it in there!

Project Files View
I'd like to call this simply "File View" from now on
Thanks for including the modified indicator. I think we should make the color a shade of red to give it more of a warning kind of feel

Sure - many IDEs are subtle and just use a shade of grey matching the text etc.. my only caution is that red could confuse people into thinking there is an error but we can test to see if that hypothesis is actually true during user testing :)

Play Button - Thanks, this improves things quite a bit
This and the Download item in the More menu are the same thing; should be same icon.
We traditionally use a play button for this "download/run" function

Got it. Ok let's do it! I'll use the play button. I think that'll be more straightforward.

Keyboard Accessory Tray
I like undo/redo and save there

Yes I'm thinking those fit well as they aid in editing as you type.

I need to consider the close, validation and grouping idea more
Having Find/Replace there could definitely be a bonus also

Thinking about it more. I think find and replace should be down there with undo and redo. I'm not sure about save and explicit close. I think those features, along with validation belong elsewhere -- in the more menu or perhaps we have save take the place of find and replace and remove the validation action from the main UI -- primarily becuase we'll validate when they hit run.

I like how it will still be visible when the keyboard is hidden
If we employ this feature, does that still work with custom keyboards like Swype?

It should. Theoretically the JS should be able to detect the viewport or screen size when the keyboard is or is not visible. So regardless of Android or iOS our accessory view should float above any keyboard as we're just placing the view at the bottom of the view minus the size reported back from the keyboard. Does that make sense? It's not actually part of the keyboard at all -- it just looks like it is.

What do you think would happen on iOS?

The same thing. BTW if you have a better idea of how you plan on packaging the app on iOS and Android I can advise further on a few details but overall it should work identically.

Source Tabs
I like it a lot, but I really want it to collapse into the top toolbar somehow to save vertical space when not needed.
Perhaps a very small down arrow (looks like a "v") at the bottom of the top toolbar (and horizontally centered) to indicate they can grab and drag it down. Then, the opposite indicate, but on the Source Tabs toolbar indicating it can be slid up, but also scrolling the actual source in the editor will cause the Source > Tab to slide up out of the way too.
The modified indicators are very important here. Thanks!

Let's discuss this more. I'll see if that's common at all. I haven't seen that done on an Android app in the past. I'm still not sure this is a good idea to do tabs. I might actually be opposed to it just because the flow to open files is to essentially close this view to return to the file view. It seems the flow would be a little strange if each time you open a file there are multiple tabs from the last files you opened.

More Menu
I like the layout
Great choice in icon or Stamp and Syntax
Remember, "Syntax" is really supposed to be "Language"
I like the icon you chose for Syntax, but with it being "Language" I'm not sure it fits anymore
I begrudgingly agree about hiding menu items from the more menu in different contexts... disabling them will maintain the sight-knowledge for the user

Yes I understand. Especially as it is a long menu. Perhaps we can eliminate a few options which I have made redundant by including them else where in the UI. I will fix language. I must have mixed that up in the notes some how. I read the note and then kept it as Syntax. Will fix.

[PropGit]

Common Actions

[Discussion is below, with quick Summary at end (after Analysis)]

To help determine the most common actions for prioritizing feature access, our Education Department identified two phases of common use for our consideration.

Usage During Educator's Course Presentations

1. Identify
2. New Source
3. Select Stamp ($STAMP directive)
4. Select Language ($PBASIC directive)
5. Enter source code
6. Syntax Check
7. Run (compile+download)
8. Save (or Save As)

The above steps are repeated several times to familiarize the audience, then they move on to development mode, below.

Development Mode

1. Open existing source
2. Edit source code
3. Run (compile+download)
   1. Modify due to error
   2. Syntax Check
   3. Run (compile+download)
4. Save (or Save As when needed for next set of modifications)

High use of Memory Map when developing space-critical code, or code that accesses EEPROM data directly.

Analysis

The above items are listed below by low, medium, and high access priorities. It's rating doesn't imply that it must be harder (low), not too hard (medium), or easy (high) to access, but gives us a relatively priority of accessibility should display and UI constraints dictate compromises.

• Identify is often used only when starting a session to verify complete development connectivity, or in bursts after a connection problem is discovered.
  • Priority: often low access needed, but good candidate for high access in session start and download error contexts
• New Source and Open Existing Source are used often at session start and at random times during active development
  • Priority: medium access needed - good candidates for high access in session start context
• Select Stamp and Select Language are most often used together and right after a New Source operation, with occasional use of Select Stamp at other times during development
  • Priority: low access - highly desired to be automatic (wrapped into) New Source operation with high access right after New Source operations, and potentially lower access all other times
• Enter/Edit (Modify) Source - most common single feature use; code editing features should be quick to activate
  • Priority: high access
• Syntax Check - used often as a sanity check without the need for a connected microcontroller or the possible disruption by induced download time delay or of the microcontroller's current operation
  • Priority: high access; highly desired to be automatic but unobtrusive, with small manual effort needed to see results if desired and easy to ignore when developer unconcerned
• Run - used often during review of examples, experiments, or active development sessions
  • Priority: high access
• Save - Used often in practice now; however, the auto-saving feature will lower the need for this in normal workflows
  • Priority: medium access
• Save As - Used often now for backup or next-design-phase purposes; however, this will be less often used in normal workflows once auto-repository features are enabled
  • Priority: low access
• Memory Map - Used infrequently expect when doing space-critical or memory intensive applications where visualizing the memory space is important
  • Priority: low access with potential high access in convenient or intense development contexts

Summary

For accessibility decisions, the recommended priorities are listed here. Items can be moved to higher priority if UI constraints allow.

High Priority

• Enter/Edit (Modify) Source
• Syntax Check
• Run (download)
• [Identify - only in session start and download error contexts]
• [Memory Map - only in certain contexts (unsure of how we'd auto-detect the context itself)]
• [New Source - only in session start context]
• [Open Existing Source - only in session start context]
• [Select Stamp - only in New Source operations]
• [Select Language - only in New Source operations]

Medium Priority

• New Source
• Open Existing Source
• Save

Low Priority

• Identify
• Memory Map
• Select Stamp
• Select Language
• Save As

[PropGit]

@jimjeffers

Project Files View
I'd like to call this simply "File View" from now on
Thanks for including the modified indicator. I think we should make the color a shade of red to give it more of a warning kind of feel

Sure - many IDEs are subtle and just use a shade of grey matching the text etc.. my only caution is that red could confuse people into thinking there is an error but we can test to see if that hypothesis is actually true during user testing :)

Perhaps yellow would be a better caution signal.

BTW if you have a better idea of how you plan on packaging the app on iOS and Android I can advise further on a few details but overall it should work identically.

I'm pretty sure we'll package using PhoneGap, but there's a chance we'll use another technology if that doesn't meet our needs.

Source Tabs

Let's discuss this more. I'll see if that's common at all. I haven't seen that done on an Android app in the past. I'm still not sure this is a good idea to do tabs. I might actually be opposed to it just because the flow to open files is to essentially close this view to return to the file view. It seems the flow would be a little strange if each time you open a file there are multiple tabs from the last files you opened.

Good points, but the flow you're speaking of is front-and-center only in the mobile platforms, all others leave code in-view during Projects Drawer and File View operations. I think you hit on the very core of why I suggested (before we met) that the filename in the toolbar be a touch target for file/project access, that slides down (animated) into view underneath the titlebar for full project/file access, and current-session open files can be swiped into/off-of view via the same filename touch target. See 17 seconds into this video.

[jimjeffers]

Some notes from our discussion this evening:

Open Indicator

• Use yellow / orange cautionary color.
• Move indicator over to the left hand side.

Fuzzy Search

• Search string should be able to match ‘%term%’ i.e. CONTAINS not BEGINS_WITH.
• CONTAINS are lower priority than BEGINS_WITH. Or possibly how soon the matching characters appear in the string. (i.e. match occurs at 3rd char vs 7th)

File Navigation

• Gestures? Hard to discover.
• Attempt a history dropdown as opposed to tabs.
• Tabs on the desktop.
• Swipe the item in the history list to close
• On desktop use tabs and eliminate back and forward buttons.

Floating Action Bar / Accessory View

• Ensure we prioritize the right actions for the bar. Make adjustments I (jim) suggested in a later edition.
• For the toolbar we might have one or more spaces available for the highest priority function.
• Jim to evaluate the priorities from Jeff and the Education team and re-evaluate the top function.. or under certain contexts. Time limited contexts that don’t last very long.

Check Syntax / Displaying Errors

• Check syntax needs to occur when we are not connected to a device or may not want to run the app..
• We discussed possibly solving this in the background.
• C language support will induce slower compilations but may still work. I need to keep that in mind.

The Floating Toolbar

• On tablet I believe it will work in a very similar fashion to the mobile.
• What to do when we have a hardware keyboard?
• On a desktop.. what’s necessary?
• Novice users tend to need toolbar items regardless of keyboard shortcuts.

New Files…

• How will we handle a file if we don’t know where it’s home is? For now we just require the user to save the pending changes if they exist before they can navigate away from the pending interface.

Archive Action

• Remind someone to save files if they want to ‘archive’ current state of the project.
• Right above settings in the project drawer.
• Could be done via share. Share the current file or project.

[jimjeffers]

@PropGit Here is an update on mobile today:

Screencast:
https://drive.google.com/open?id=0B53rXRf-3dMidTZnUDlkZXdnN2c

PDF:
https://drive.google.com/open?id=0B53rXRf-3dMiRVBHZEhHWWFFMUU

Hope to get you one more on Tablet / Desktop tonight.

[PropGit]

@jimjeffers Thank you.

Project Drawer

• I envisioned "Parallax IDE" on one line, but the stacked way you put it to save font size and fill in space is kind of growing on me
• Thanks for incorporating the colors and your choice of the green for primary action
• Is the "Projects" and "Files" section headers one of the colors in our scheme?

Search

• Perfect!

File View

• The New File icon needs a + sign.
• Item to ponder: I keep wondering if we could/should place the New Folder and New File buttons on the right side of the Folders and Files section headers (aligned with the more buttons) instead of down on the FAB.
  • Thoughts: If there are no folders, we could hide the Folders section header and just show the Files label... which would hide the New Folder button too, unfortunately. However, if there are no files, we'd never want to hide the Files section header, which makes this behavior inconsistent. So, that makes me want to keep the Folders section header, regardless, and perhaps adorn it somehow when it's empty.
• I like the modified indicator color and filename indention

Editor

• Recent Files dropdown
  • The dropdown icon on the filename is something I didn't anticipate; it takes a lot of space.
  • When the dropdown is activated, is it unreasonable to make it leave the current filename essentially untouched (at the top) and allow the history items to drop below it and also extend to the right to accommodate even wider filenames? Like this?
    
• Directives
  • I like the idea of making the $STAMP and $PBASIC directives an active part of the source- adjustable by native; I'll call them overlaid action bars.
    • NOTE: We encourage, through example, that these directives be near the top of code; however, they are not always at the very top of code, often there are a few source code comments above them. It's possible for syntax errors to highlight these directives also. Perhaps we can perform some editor trickery where navigating the cursor onto those lines causes these overlaid action bars to become visible and focused.
  • The $STAMP directive has optional filenames after the module type, for every type beyond the BS2... for example, {$STAMP BS2e, "Slot2Code.bs2", "Slot3Code.bs2"} is a valid directive if the referenced code exists in the project. We'd need a way for the app to highlight syntax errors here, and also for the user to be able to type in (or select) filenames for these optional fields. Such projects can have zero (0) to seven (7) file references.
• Syntax Check and Run buttons
  • My priority list may have implied too much- the automatic background syntax check idea eliminates the need for an always-available manual Syntax Check button.
  • The Run and Syntax Check features are mutually-exclusive. The Run is only truly possible if the background Syntax Check passed.
  • Let's free up the Syntax Check position for an optional high-priority context button (or just blank) and combine Syntax Check with Run in the Run button's position.
    • When editing source, the button becomes a Syntax Check icon (perhaps yellow). This indicates that it needs to perform, or is performing, a syntax check.
    • When Syntax Check passes, it becomes a Run icon. Activating it attempts to perform a download.
    • When Syntax Check fails, it becomes an exclamation point (or perhaps a red Syntax Check) icon. Activating it navigates to and highlights the offending source and displays the error message.
• Context-Button (occasional high-priority item)
  • When syntax is valid, this can be a Memory Map icon
  • When Run failed (due to download error), this can be an Identify icon
• More Button
  • I like having the Save function in this menu
  • Memory Map can be removed if we make it high-priority context active
  • Identify can be removed if we make it high-priority context active
    • NOTE: Alternatively, we could leave Memory Map and Identify in the menu (just disabled/enabled in the right context) so people learn what the icon means that occasionally appears in the Context-Button space.

[jimjeffers]

@PropGit

Is the "Projects" and "Files" section headers one of the colors in our scheme?

Yes. It is the medium blue color. Correction, the section headers are not in the color scheme... this will be fixed.

Context-Button (occasional high-priority item)

Sounds good. When there is not a special situation -- do we simply display only the run / validate button?

NOTE: Alternatively, we could leave Memory Map and Identify in the menu (just disabled/enabled in the right context) so people learn what the icon means that occasionally appears in the Context-Button space.

That could be better - my only concern is that people may get confused about memory map -- i.e. they won't know why it appears when it does or why they can't access it from the side menu when it's disabled. We'll definitely need to so some user testing in the wild to see how the context sensitive button pans out but I like the idea overall as it simplifies the interface by removing irrelevant complexity from the user!

Let's free up the Syntax Check position for an optional high-priority context button (or just blank) and combine Syntax Check with Run in the Run button's position.

Sure - I've updated mockups accordingly. Not sure whether or not we need to do colors or not but I can set it up so we can see how it looks!

Directives

Hmm there goes that idea! :) It's not that simple I suppose. I'll chat with you more on this but it might be best to revert back to providing them as menu options / context sensitive.

Recent Files dropdown

I've adjusted this a bit per your feedback. Should be more to your liking. I have a small arrow indicating a dropdown instead of that large clunky arrow. The dropdown is wider but covers the currently selected file. This is just per googles convention:

[PropGit]

Context-Button (occasional high-priority item)

Sounds good. When there is not a special situation -- do we simply display only the run / validate button?

Yes... either a blank spot where the Context-Button would have been, or perhaps ideally, a gentle animate-stretch of the filename's width to occupy that blank space.

NOTE: Alternatively, we could leave Memory Map and Identify in the menu (just disabled/enabled in the right context) so people learn what the icon means that occasionally appears in the Context-Button space.

That could be better - my only concern is that people may get confused about memory map -- i.e. they won't know why it appears when it does or why they can't access it from the side menu when it's disabled.

Right. It's not possible to see the memory map if it can't compile. Not sure how we'd explain that to people with brevity... except through this interaction and their experience.

[PropGit]

Directives

Hmm there goes that idea! :) It's not that simple I suppose. I'll chat with you more on this but it might be best to revert back to providing them as menu options / context sensitive.

Yes, let's chat about that; I thought of a hybrid approach that, while probably not super easy to implement, would be really nice.

Recent Files dropdown

I've adjusted this a bit per your feedback. Should be more to your liking. I have a small arrow indicating a dropdown instead of that large clunky arrow. The dropdown is wider but covers the currently selected file. This is just per googles convention:

I had a feeling the "cover" behavior was unavoidable using Google's convention. :-(

[PropGit]

Updated mobile mockup screencast and also PDF is here.

[PropGit]

Updated desktop mockup screencast and PDF is here.

[PropGit]

@jimjeffers - Here's my desktop mockup feedback:

Project Drawer

• Perfect - Looks the sames as on mobile; great!

File View

• Condensed folder/file view - Good.
• We want to be able to show and hide this view (ie: slide this view all the way to the left) leaving just the menu button on the toolbar when hidden. Hiding this will give us the sometimes-precious horizontal editing space we need to focus.
• Because of the above (and other factors) I need the tabs to show the project/folder they belong to, like on Mobile.
• I'd like to shrink the green tool bar vertically, but I forget about touch-screen devices now... they need bigger targets. Not sure what to do here; probably leave it as is.

Editor

• Again, my first instinct is to shrink the tool bars vertically but I think we should hold off on that. I wish there was a precedent already for the same application across large screen legacy vs. touch interfaces. It'd be nice if it could auto-detect and adjust touch targets bigger (when touch is in use) and shrink to more refined (when mouse/keyboard are in use). This is likely something we'll start seeing trends on soon as single-source multi-device software is slowly evolving to become the norm.
• Tabs
  • Please add the small-font Project > Folder(s) indication under the filenames on the tabs. This will be critical feedback for handing mixed project files in the same session.
  • We can make the File View follow the tab (ie: update to point to wherever the selected tab references) but I'm not sure we want to do that. I'll need to consider this further.
• Toolbar
  • I think you're right, we'll probably want to move a couple low-priority items into the more menu. I'll consider this further.
• Multiple Project Files
  • This is a concern of mine too; however, having the project > folder shown with the name, and possibly having the File View (and it's Project title above it) actively follow the selected tab (active source) it should help keep it clear to the user. This is a superset of what you thought of during the screencast.

[jimjeffers]

Touch vs. Keyboard

• For right now stick with large touch targets in hopes of a better solution in the future to address all cases without being annoying.
• Hiding the file view on desktop. Make it sticky on desktop but not on mobile.
• It’s important that we keep the tabs consistent. Possibly something like intelli-j.

More Menu on the Editor

• ‘Save as’ could be in the more menu.
• Move the share feature into the more menu.
• File icon with a PLUS in it?
• Edit google’s design icon so that it has a plus in it.

Interactive Mockups

• Show the FAB animation on scroll in file navigator - Done.
• Show the show and hide transitions for the project drawer and the file view - Done.
• Dropdown to navigate to recent files. - Done.
• Switching projects in the file drawer - some of the sub menus - Done.
• ‘SER’ live search for keyboard input. - Done.
• Live search - show when no results. - Done.
• Use Jeff’s runtime keyword in ‘example code’ directory on drive for example on syntax error.

Schedule

• Jim to verify FramerJS can share interactive prototypes as hoped.
• Jim to provide mockup revisions today.. interactive mockups to be delivered tentatively on Thursday w/ Friday discussion.

[jimjeffers]

Per our last conversation. Some of the interactive mockups have been completed:

Desktop file navigator show / hide:

https://drive.google.com/file/d/0B53rXRf-3dMiWE4yN2pnYjktaGM/view?usp=sharing

Interactive version:
http://share.framerjs.com/0l61zk9qb2gc/

Mobile File Navigator Toolbar Transitions

https://drive.google.com/file/d/0B53rXRf-3dMiNDVMMmVNUGhnekE/view?usp=sharing

Interactive Version:
http://share.framerjs.com/w3esaw2pt2yv/

[PropGit]

@jimjeffers - Thanks.

• Desktop File View
  • Please make this slide out (animate) when the Project icon is clicked; like the transition of the Project Drawer.
  • I still think it'd be good on desktops and tablets (that have the screen space) to provide a button to hide the File View. Like this, perhaps, where the button doesn't get hidden when the view slides out, but rather the button slides to the right, just like the tool bar does, and transitions to an opposite facing button to indicate it's new action:
    
  • Will it be possible to swipe right from the left edge to bring the File View out?
• More Menu
  • The touch target is too narrow; that's why it's hard to activate that in the framerjs demo
  • This menu looks good
• New File
  • Looks great with the plus
• Mobile File View
  • FAB padding - perfect!
  • Animation - it's nice to see it in action
  • Ripple animation - That looks great!
  • In the interactive, the FAB is still visible on-screen after the floating action bar is visible.
    

[PropGit]

@jimjeffers
Updated Debug Console - Resizing works great. Is it ready to accept text into the Transmit Pane? I wasn't able to type anything there.

Updated Compilation Timing - That's much better! Thank you.

[jimjeffers]

@PropGit Is it not working for you? It should allow text entry via your actual keyboard. Not by clicking on the fake on screen keyboard. I will check in Chrome. It works in Safari.

[PropGit]

@jimjeffers - I see, it does indeed work with hardware keyboard, but only when Debug Terminal is full screen.

[jimjeffers]

@PropGit Right! There was a bug. Now if you tap on the field it will launch into full screen with the virtual keyboard:

http://share.framerjs.com/4lwlryiuyq28/

The idea is you'd need to be in full screen if you actually want to transmit on mobile as you're going to be using the virtual keyboard in most cases and screen real estate is too limited. Thoughts?

[PropGit]

I see. I think that works well for mobile (phone), but may not necessarily apply to tablet and certainly not desktop. When we get back to those interactives, I'd like to explore making it take advantage of the extra
screen space to allows virtual keyboard input (or hardware keyboard) even when the Debug Terminal is not full screen.

[jimjeffers]

@PropGit Agreed! I think in the case of mobile - if a hardware keyboard were detected - we could disable the transition to full screen. On tablet/desktop this won't even be a design consideration as the debug console will not usually be fullscreen, if ever.

[jimjeffers]

Find and Replace (Mobile)

On mobile we will have limited screen real estate. The interface for find and replace is built off the accessory view where the find and replace button is displayed.

1. When you tap the find and replace button in the accessory view - the accessory view will be replaced by the find and replace pane.
2. Tapping the X in the top right corner of the find and replace interface will hide the find interface and return to the normal accessory view.
3. Tapping into either field will cause the fields bottom line to change to an active color as is standard in google’s material design.
4. The find field will show a count of ‘X of TOTAL’ matches and also has two adjacent arrow buttons to jump between matches.
5. The replace field has a ‘done’ checkmark icon that activates when a match is found and a replacement string exists. Tapping the checkmark will replace the current match and jump the user to the next available match.
6. The magnifying glass icon will take the user to the next match and cycle back to the top of the document if the user has reached the final match on the page.
7. The more menu will provide a dropdown menu that will allow the user to toggle advanced search settings.

PDF Document

https://drive.google.com/file/d/0B53rXRf-3dMiemE4cjUtTjlSTE0/view?usp=sharing

Screencast

Updated UI:

https://drive.google.com/file/d/0B53rXRf-3dMiUkFNQXFvYlU4S1k/view?usp=sharing

Deprecated UI:

https://drive.google.com/file/d/0B53rXRf-3dMiUy1tbEdXMGlPbkU/view?usp=sharing

[jimjeffers]

Hey @PropGit I've updated the find and replace screencast and PDF with an updated UI that allows for more advanced functionality such as case sensitivity and partial/whole word toggles. I also replaced the next/previous button with one search button to simplify the UI given how compact the UI is.

[jimjeffers]

@PropGit The original file navigation demo will now actually adjust the code contents when you switch between projects:

http://share.framerjs.com/u87mxiqrfioa/

Also - I've added some documentation for this demo to the master document:

https://docs.google.com/document/d/1AZIVgcckDK1XsJvnb4-j_FkSNyKqPzBif2twwZN0ccg/edit?usp=sharing

[jimjeffers]

@PropGit

Import / Export Buttons

I've added the import and export buttons so that those operations can now be done at a project and file level. I've also added the functionality.

1. To import/export a project, use the options located on the project drawer.
2. To import/export a file use the contextual menu or the more menu within the IDE activity.
3. I've provided a sharing sheet to show how the work flow could continue if a user clicked on sharing. This could also be applied to the import/export workflows but we have to define how those will work in depth. At this point we've only covered how to access them.

Screencast

https://drive.google.com/file/d/0B53rXRf-3dMiLUlGNnNNaXQ4c3c/view?usp=sharing

PDF Document

https://drive.google.com/file/d/0B53rXRf-3dMiV3l6bGJnTFBBbVU/view?usp=sharing

[PropGit]

@jimjeffers

Find and Replace (Mobile)

Great start! I like all the features you display and the behavior described, especially the "x of total" indication. Below is some more feedback and ideas.

• Since Replace tends to be used much less often... I'm tempted to find a way to hide that feature until the user calls for it. Maybe there's no room for a button for that... and a gesture to expand the accessory view (to reveal Replace) may be too hidden for most people to find.
• If Replace is always visible, then there's extra room below the X to place the more (...) button, which gets the show next and replace buttons further from the X and more (...) button; avoiding accidental hits.
• The briefer, check-to-enable/uncheck-to-disable implementation is preferred for the more menu, showing "Whole Term" and "Case Sensitive" items only.
• The behavior for the Find field should be: as the user types (or edits the field contents), the "x of total" indicator should update and the editor should also update to reveal all the matches. This makes for a very active, responsive system, almost eliminating the need for a search next or search next/previous button.
  • On that note... Let's ponder - for mobile and other touch interfaces... what if there were no search next/previous buttons... but rather the user simply gestured in the editor (flick up / down) to find the previous / next occurrence?
  • They could also simply tap the occurrence to select it as the active occurrence that can be replaced if desired.
• When closing the Find/Replace feature (with the X), I think we'd want the cursor to appear immediately after the last active occurrence (if any) from the previous Find/Replace operation.
• I'd also like to see that the keyboard slides away and the accessory view slides down to the bottom of the screen either when the user gestures in the editor or touch-slides the accessory view downward, revealing more precious editor space for searching and enabling the user to get their bearing about the location of the found item in the source.

[PropGit]

@jimjeffers

The original file navigation demo will now actually adjust the code contents when you switch between projects.

Fantastic! Thanks, it works!

[PropGit]

@jimjeffers

Import / Export Buttons

I've added the import and export buttons...

Those options and your described operation look good.

• I think the icons for Import and Export need to be visually opposite each other
• I like the share sheet appearance
• [Jeff] need to still consider input button on action bar to input files into project/folder
• [Jeff] need to decide and discuss Import / Export workflow

[jimjeffers]

Thanks @PropGit I'm going to implement some revisions today and also work on the directives. If you're free we could chat tomorrow to cover all of the ground we've covered now. I think the entire list is covered except the dialogs which we'll have to do at the start of next month's iteration as we're going to run out of hours in this month pretty soon!

[jimjeffers]

@PropGit Perhaps on find and replace I will hide the navigation bar until the find and replace is dismissed. This should open up a noticeable amount of editor space.

[jimjeffers]

@PropGit I'm hesitant to perform a gesture based find and replace as just from personal experience in IDEs I'm used to scrolling the document and reviewing the highlighted areas as well as using the search button to jump to the next occurrence if I need to.

[jimjeffers]

@PropGit I'll try out a version where you have to actually toggle replace to see the full interface! I thought about it but was having trouble finding the space for the extra button that could do this. I'll brainstorm a bit more! If anything it could be on the more menu.

[jimjeffers]

@PropGit I've updated the find and replace demo:

1. Simplified the more menu to opt with the toggle solution.
2. Added an option to toggle the replace field on and off via the more menu.
3. The navigation bar is hidden when find/replace is active.
4. The navigation bar reappears if the keyboard is dismissed but find and replace is still active.

PDF Document

https://drive.google.com/file/d/0B53rXRf-3dMiTzVXZHBDZnhVMGs/view?usp=sharing

Screencast

https://drive.google.com/file/d/0B53rXRf-3dMiTm9qSTRVNkhsMEU/view?usp=sharing

[jimjeffers]

@PropGit

Directives

This is more of a brainstorming post than anything. But I'm thinking we can use a little helper icon such as a lightbulb on special lines of code where we can provide a menu of suggestions to the user. This is how intelli-j handles code suggestions and it works quite well in Android Studio. I also discuss some ideas on how we're going to handle new files on mobile. We discussed this before but it will be important to figure out how we will handle this as it will also segue quite well into the dialogs we still have to design.

Let me know your thoughts!

https://drive.google.com/file/d/0B53rXRf-3dMiX1ZOQ3ZRc1NqQnc/view?usp=sharing

[PropGit]

@jimjeffers

Perhaps... I will hide the navigation bar until the find and replace is dismissed.

Excellent idea.

I'm hesitant to perform a gesture based find and replace...

Understood. I have a suspicion a natural feeling interface can be had, but I don't know the solution and can't afford the time to dream it up right now, so we'll leave that idea on the back burner.

1. Simplified the more menu to opt with the toggle solution.

Thanks.

1. Added an option to toggle the replace field on and off via the more menu.

Oh that works great! I like it!

1. The navigation bar is hidden when find/replace is active.

Fantastic!

1. The navigation bar reappears if the keyboard is dismissed but find and replace is still active.

Ideal!

Directives - lightbulb idea

Yes! That feels much better! I prefer the lightbulb appearing only when the cursor is on the related statement line; this, for the reason you noted, that it's hard to tap the correct one if there are two that are close to each other.

I think the drop down menu should appear below the line that it relates to. This is partly so the user can still see the line they are affecting, but also because it's confusing when there are two adjacent lines that are special like this.

New File - 'X' to close

I'm glad you've brought this back up. Yes, the 'X' is a fantastic idea here. Clicking the 'X' should prompt the user to save or confirm the discard of the new file. There's a feature we are used to having in our legacy editors where no files actually need to be saved before actually using them in a compiled project. This feature covers the case if we don't choose to implement that (which it isn't implemented yet), so it's something we may choose to replace in the future.

[PropGit]

Dialog Design

Here is a list of dialogs and screenshots from our current dialog designs where they already exist.

• Save

  • The save dialog normally isn't seen but appears automatically in certain cases
  • Case 1: A user-selected Save operation displays the dialog when the file has never been saved before (ie: it's a new file)

    • Our goal is to make the existing dialog (below) use a different title, "Enter a name for this new file." and also change the "Save As" button to a "Save" button.

      

  • Case 2: If the user tries to navigate away from a new file, another slightly-modified dialog appears that includes a "Don't Save" option.

    • Goal: to make the existing dialog (below) use a button called "Save" instead of "Save As"

      

• Save As

  • Goal: change the existing dialog (below) to have a title "Choose a name to save this file as."
    

• Delete

  

• Identify / Download

  • Identify and Download are combined into one dialog in Parallax IDE.
    • Goal: We need to enhance it a bit to distinguish the displayed functions, as discussed verbally.
    • Goal: Would like the "Please choose..." message to appear at the bottom, only when the context is right (which is after scan is complete in cases where it can not automatically determine which module to download to).
    • Goal: Make the dialog more compact, and auto expand/contract if there are more/less ports to display.
  • Case 1: [Identifying] Just opened... scanning ports
    
  • Case 2: [Identifying] Found two ports, but no devices found. Status message for this case is too long; would like a more vertically compact dialog. Status is really an error message, it is blank when all is well.
    
  • Case 3: [Identifying] Found one BS2p module on COM17
    
  • Case 4: [Identifying] {Not Pictured} Found two or more modules of same or different types.
  • Case 5: [Downloading] Found two ports, one BS2p, and downloads to it (very fast). This is best shown as a video, below.
    Dialog Video

• Change to / Create Project
  

• Import

• Export

• Share?

• Missing Directive

[jimjeffers]

Find / Replace

• Add mockup with nav bar visible when keyboard dismissed if not there already.

Lightbulb

• Menu should appear just below the line.
• If directive is missing show an auto-inserted error on the top of the file. App will not compile and they can choose the right directive.

Import/Export

• Use the same icon flip/flopped.

[jimjeffers]

Thanks for the dialog info @PropGit

[jimjeffers]

Hey @PropGit! Sorry I have gone missing since we last chatted. I had come down with a pretty bad cough / cold and fell behind schedule this month. I still have a bit of this irking itch in my throat which I hope is not too distracting in the screencasts. I tried to edit out the coughing where I could! First off. I wanted to touch on the general house keeping revisions we discussed per our last call. I'll make sure these updates make it into their associated PDF's that I already have linked to in the documentation.

This screencast covers revisions to:

• Import/Export icons.
• Suggestion menu (lightbulb menu)
• Missing directives
• Find / Replace without the keyboard

Take a look when you can:

https://drive.google.com/a/sumocreations.com/file/d/0B53rXRf-3dMiMzRNQjhaWXhVR3M/view

[jimjeffers]

@PropGit Get ready for a mobile dialogs marathon:

In this screencast I run through pretty much every dialog box that we will likely plan on implementing in the initial version of the editor. The only exclusions and the areas we need to have discussions will center around how we want to approach 'help' and 'settings'.

Screencast:

https://drive.google.com/a/sumocreations.com/file/d/0B53rXRf-3dMia0d1U0ZiQm13QXc/view

PDF:

https://drive.google.com/open?id=0B53rXRf-3dMiN2RGdU5OV1BPQ1U

[PropGit]

@jimjeffers - I've reviewed the screencasts.

• Missing directives

Excellent! Looks better than I imagined and very clearly defines the problem to the user. I like your idea of adding the message in the code font that looks and acts like a hyperlink.

• Suggestion menu (lightbulb menu)

The lightbulb is perfect. To verify, I do like having the menu drop below the line that it applies to; that works great.

• Find / Replace without the keyboard

That looks great without the keyboard. Thanks for showing that.

• Import/Export icons.

That's a good attempt, but it still doesn't strike me the way I was hoping. The fact that there's two arrows in both cases is the point of confusion. I've got an idea! Take a look at the share icon; it's a dot (representing a project/file/place that connects out to two other dots (places) via lines to represent sharing one thing to possibly multiple others. How about we use that concept and take make two dots and the line going between them (angled from top-left to bottom-right) and make the line an arrow facing the bottom dot. That's "import." Then the export is that same icon rotated counter-clockwise so it goes from lower-left to upper-right. The point is, in each case, the bottom dot is the "place of concern" where the external item is being imported to, or exported from. Let's talk in our meeting about this.

• Dialogs

I think you're hitting the target well.

Navigating Away from a New Unsaved File

Excellent!

• Please change the message to, "You will lose the code you've just written if you do not save it now."
• Please add a Cancel button too (that simply closes the dialog and cancels the navigation that led to it)

Scanning

Fantastic simplification.

• I like the progress bars
• As discussed, we'd like to show port (in result) in small text under the device/response text to allow for long port names
• I can envision an animation from the moment of selection of a port to the downloading dialog

Move

• As discussed, need an indication of the project we're showing
• item for "other" that causes it to show the project list for the user to select from and navigate down to the desired subfolder

Import/Export

As discussed, this it to get projects or files into/out-of the applications storage area

[jimjeffers]

@PropGit The PDF for the dialogs has been updated with:

• New import/export icons
• Updated move work flow that allows you to move file to another project.
• Updated import/export workflow which uses a share sheet with less options to export file/folder to google drive etc.. an example (imported screenshot from the google drive SDK) to illustrate how the user would select a file from their google drive.

The updated link is here:
https://drive.google.com/open?id=0B53rXRf-3dMiN2RGdU5OV1BPQ1U

[jimjeffers]

@PropGit Also I made some updates to the identify dialogs so that they show longer device names, the current port getting scanned, and longer custom names that are truncated.

[phated]

I have a feeling all the dialogs with textboxes in them are going to be a nightmare to develop since web applications don't have access to height of the keyboard, etc. Are they really best as dialogs?

[jimjeffers]

@phated We can display them as full screen modal views if that is the case.