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 #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 https://github.com/parallaxinc/Parallax-IDE/issues/318#issuecomment-160754192.

[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.

[jimjeffers]

@PropGit Thanks for the feedback. I just looked into that last issue. Looks like ab ug with framer's viewer. It works in Safari but not in Git. I will see if there's anything I can do to fix it within framer.

[jimjeffers]

Some notes from today's discussion:

Begin considering deeper interactions such as the debug terminal.

• Console allows echo or not echo.
• Console will allow you to control baud rate and device port.
• On mobile the console will need to be full screen — our current mockups do not make the console accessible enough to the developer so we will most likely want to workout a situation where the debug icon exist on the keyboard accessory view and can be accessed via a swipe or tap on the debug icon. We intend for a swipe up / down approach to toggling the console on mobile w/ a button so that less advanced users can become aware that the console panel is accessible ‘down below’ the code.

For this iteration:

• Jim to continue where we left off on interactive mockups in framer.
• Jeff / Jim to discuss mockups for more advanced features that have yet to be designed. (debug, identify, etc.)

[PropGit]

@jimjeffers I'm confused by something in the Mobile mock ups. When in the editor view:

The upper-left icon is a left arrow, indicating that we're in a nested activity, right? Selecting that takes us back to the file view?

and only from there can we get back to the project drawer?

If we had selected a project, the selected a subfolder, then a file; that seems like the interaction to get back to the main menu would now take three steps. I think we need to find a way to alleviate these extra steps.

[jimjeffers]

@PropGit Agreed. I think our compromise or solution here was the quick file switch which allows to switch between projects. OR the autocomplete for file search matches files, folders, and projects. So those alternate paths would be quicker routes to get to different files or projects. Do you think this could be sufficient or should I reconsider the mobile nav in the file switcher?

[PropGit]

UPDATE:

Here's a 6 minute video I recorded to give our Parallax Team a walk-through of our mocked up design for the official Parallax IDE. These are mostly static mock ups that I'm making look dynamic in the video; just politely ignore graphics that shift around in transitions.

https://drive.google.com/file/d/0B0tev9Y3WaL4T1dDeWdXczVzeHc/view?usp=sharing

[jimjeffers]

@PropGit Looks great. That's some fancy screen dancing with static mocks!

[jimjeffers]

I've done some house keeping per the feedback we had on the last iteration of interactive mockups. Framer generates a new URL each time I share a prototype so here are updated versions of the last prototypes I deployed:

1. Fab scrolling now properly clips the Fab in Chrome: http://share.framerjs.com/46p699tk97ni/
2. Here are revisions to the desktop mockup in which you can now swipe to open the file explorer, the button to compact or expend is persistent, and the more menu on the right hand side has a larger hit target: http://share.framerjs.com/9bpuwdg3606n/

[PropGit]

@jimjeffers - Great! Both items verified and I like them!

Try expanding the file view and then click the Menu button; funny thing happens.

[jimjeffers]

@PropGit I've added a lot of demo functionality to the mobile file nav.

Updated Mobile Navigation Prototype

1. We can now navigate to the search screen and type real keyboard input into the search field. It will only respond to 'SER' if you type anything outside of that you'll see 'No Results Found':
2. You can summon the project drawer via swipe or tapping the menu button:

http://share.framerjs.com/924y21zuyn1a/

TODO:

1. Hoping to add project switching tonight. This should give some context as to how we expect the project toggling to behave.
2. Navigating to the code view.

I think from that point I'll create a seperate framer to demonstrate changes that occur within the code view. The reason is that the framer project will become overly complex and difficult to maintain. So I'll try to provide hooks in any of the framer prototypes where you can navigate to a screen that is no longer interactive indicating you've reached the end of a given demonstration.

[jimjeffers]

@propgit I can resolve this by making the layer below an interactive later. Seems to be a bug with framers scroll component. I had to deal with that specific issue on the updates to mobile.

Sent from my iPhone

On Jan 13, 2016, at 4:16 PM, Parallax Git Administrator notifications@github.com wrote:

@jimjeffers - Great! Both items verified and I like them!

Try expanding the file view and then click the Menu button; funny thing happens.

— Reply to this email directly or view it on GitHub.

[jimjeffers]

Mobile Navigation Prototype V2

• Added the ability to switch between projects when viewing the project drawer.
• You can open the code editor by tapping on the first file item.
• You can see the more menu by tapping any of the 'more' buttons on a given file or folder.
• You can show or hide the keyboard in the code editor.

http://share.framerjs.com/22b2efzxlghh/

Please excuse some loading time - the first time you jump to a view the images for the view may need to load.

Let me know your thoughts! We're getting there...

[jimjeffers]

Mobile Navigation Prototype V3

• Fixed bugs relating to the project switcher drawer showing the wrong project.
• Fixed bug causing the keyboard to appear erratically in the code editing view.
• Fixed bug causing the code to scroll to an improper constraint when the keyboard was not visible.
• Added the ability to show the jump menu to switch between projects.
• Added the ability to launch the more menu in the code editor.
• Added the ability to delete the last item from the code menu.

Notes:

I'm still trying to figure out a good way to handle the appearance of a tokenization error or jumping to another file. I think I may just use the screenshot of the err example as the contents of the other file. Since we just have images here I can't actually fake some code entry so this might be the best demonstration.

http://share.framerjs.com/cqhit8uf9ulb/

[jimjeffers]

Mobile Navigation Prototype V4

• Completed the illusion of file switching.
• Improved the 'delete' from jump menu demonstration.
• Fixed some bugs causing files in the main navigation to detect false clicks when scrolling.
• Both cases where the keyboard gets displayed are accurately presented w/ the default android behavior to hide the keyboard or go back.

http://share.framerjs.com/2c41hlwie6sq/

@PropGit I have added a screencast demonstrating the latest iteration of the mobile file nav prototype here: https://drive.google.com/a/sumocreations.com/file/d/0B53rXRf-3dMiM2VOYnluZ29qSVE/view

[PropGit]

@jimjeffers

I'm responding to a number of versions of the interactives... ignore comments if they've been fixed in later versions.

Updated Mobile Navigation Prototype

1. We can now navigate to the search screen and type real keyboard input into the search field. It will only respond to 'SER' if you type anything outside of that you'll see 'No Results Found':
2. You can summon the project drawer via swipe or tapping the menu button:

Search and Project Drawer interactions verified! Fantastic!

I can resolve this by making the layer below an interactive later.

Does the resolve the overly complex framer project issue?

Mobile Navigation Prototype V2

• Added the ability to switch between projects when viewing the project drawer.

This interactive simply toggles open project, sometimes making the resulting view show the wrong project.

• You can open the code editor by tapping on the first file item.

Verified, but this works for the first two file items, but always shows the same code view, which isn't the right source name. Also, doesn't seem to have a touch target that covers the whole row (minus the more button).

• You can see the more menu by tapping any of the 'more' buttons on a given file or folder.

Perfect!

• You can show or hide the keyboard in the code editor.

Verified!

Mobile Navigation Prototype V3

• Fixed bugs relating to the project switcher drawer showing the wrong project.

Still broken for me. If I click on the same project each time, it still toggles projects.

• Fixed bug causing the keyboard to appear erratically in the code editing view.

Not sure, but I think this is working fine for me.

• Fixed bug causing the code to scroll to an improper constraint when the keyboard was not visible.

Seems perfect now.

• Added the ability to show the jump menu to switch between projects.

Awesome! Can we add ability to open code view for that first item in the jump menu? Done... I see it now in v4.

• Added the ability to launch the more menu in the code editor.

Verified!

• Added the ability to delete the last item from the code menu.

Code menu? You must mean jump menu: verified! Let's call it the Active Source list.

I'm still trying to figure out a good way to handle the appearance of a tokenization error or jumping to another file. I think I may just use the screenshot of the err example as the contents of the other file. Since we just have images here I can't actually fake some code entry so this might be the best demonstration.

Agreed.

Mobile Navigation Prototype V4

• Completed the illusion of file switching.

Perfect!

• Improved the 'delete' from jump menu demonstration.

Great! Looks like it's the second item in the active code list that's deletable. Verified.

• Fixed some bugs causing files in the main navigation to detect false clicks when scrolling.
• Both cases where the keyboard gets displayed are accurately presented w/ the default android behavior to hide the keyboard or go back.

Verified.

I have added a screencast demonstrating the latest iteration of the mobile file nav prototype

Thanks! That helped me understand a few things I couldn't figure out before.

This all looks fantastic!

[PropGit]

@jimjeffers - Request for comment: I'm no longer seeing a true benefit in having the green action bar (at the bottom of the File View) animating away into a FAB. If we're making the scrolling list provide enough padding at the bottom to allow scrolling up out of the way of the FAB, then it naturally also scrolls up out of the way of the green action bar. I think we started down this path to prevent taking up two rows of space to allow adding a new folder and new file, but now we've compressed that down to one row, that can always be visible.

I'm leaning towards keeping it a green action bar always.

Thoughts?

[jimjeffers]

@PropGit Outside of it being a nice effect - it is some unnecessary complexity in the UI. It affords you more screen real-estate to read the list, but if most smartphones have a larger display as they do today, than I think it could be safe to forego this element in the actual interface as well!

[PropGit]

@jimjeffers - Okay, let's make it a fixed green action bar then. Sorry to have wasted time on this, but some things are not obvious until we implement them.

[jimjeffers]

@PropGit - I've uploaded a new screencast demoing the debug console on mobile. Please take a look:

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

(Also see this post) Changes in this update include:

1. The new file/folder menu does not disappear when you scroll. The fab is no more! Long live the new item menu!
2. I've added a swipe up interaction as well as a tap on the keyboard accessory view in the code editor. This allows you to quickly navigate to the debugger console while coding. The debugger console also has it's own accessory view with the Echo,TX,RX items serving as the contextual items for the view which will be visible at the bottom of the screen whether the keyboard is active or not.

Also note:

I've hit a limit on the allowed file size for a demo that I can share. So moving forward I'll have to break these apart into individual demonstrations that we can share online. I thought we could just keep adding on to one framer project, but it's not really intended for that and thus my goal will be to create specialized prototypes that only show a specific interaction for upcoming works.

[PropGit]

@jimjeffers - I'll provide feedback as soon as possible.

The shared interactive limitation is a bummer, but we can deal with it the way you indicated. Sounds reasonable.

[PropGit]

@jimjeffers

The new file/folder menu does not disappear when you scroll. The fab is no more! Long live the new item menu!

The screencast shows the green toolbar still transitions into a fab. Am I misunderstanding what you meant?

Do you have a new interactive to publish?

I've added a swipe up interaction as well as a tap on the keyboard accessory view in the code editor. This allows you to quickly navigate to the debugger console while coding. The debugger console also has it's own accessory view with the Echo,TX,RX items serving as the contextual items for the view which will be visible at the bottom of the screen whether the keyboard is active or not.

The debug console is not shown in this screencast.

Maybe you linked to the wrong screencast?

[PropGit]

@jimjeffers Found it. Here's the debugger screencast: https://drive.google.com/file/d/0B53rXRf-3dMiYzJEOXExbk5uWHc/view?usp=sharing

The permanent new file/folder menu is great. The swipe up (or tap) to reveal the debug terminal is perfect. Animation is fantastic too. Great work!

[PropGit]

Next Design Elements

NOTE: Ideas are welcome. Struck-through items are done.

• Show Syntax Error Done.
  • Make this in interactive
• Show source change Done.
  • when selecting each of the top two items in the jump list Done.
• Import / Export / Share Done.
  • Project and file storage is closely managed by the app. This increases storage integrity but prevents direct access to the resources. As such, facilities enabling the user to bring projects/files in, or pull them out are vital. For each of the project and file entities, we need to add functions for Import, Export, and Share.
  • Import and Export should be options on the main menu (only?) Done.
  • Share should be on the main menu (for project sharing) and source menu (for file sharing) Done.
  • Ideas welcome
• Debug Terminal Done
  • Make sure a swipe up (or down) gesture is able to size the debug pane, so a partial view of debug and source is possible. This is necessary on all platforms but will be more frequently used on larger screens.
  • Add transmit pane (short text entry pane right above receive pane). This will allow text entry from the keyboards whereas the receive pane only shows text received from microcontroller.
• Landscape orientation Done.
  • Can mobile interactive show landscape orientation naturally? If that takes significant work, just a static set of mock ups in landscape orientation is desired. Done.
• Directives ($STAMP and $PBASIC)
  • We'd like these lines to appear as normal text in the source, but when the user touches one of them, it transitions into the control that is needed to modify it.
• Find/Replace (in source) Done.
  • A visually-compact implementation is desired but with a better look than the current implementation and more features
  • Icon should be distinct from project/file search (maybe placement is all that matters?)
  • Options
  • Match case Done.
  • Match partial Done.
  • Next/Prev/Replace/ Replace All buttons
  • Google Chrome's and Google Doc's compact Find feature is an inspiration:
• Dialogs
  • Save
  • Save As
  • Delete
  • Identify
  • Download
  • New Project
  • Import
  • Export
  • Share?
  • Missing Directive

[jimjeffers]

@PropGit Sorry about that! It was incorrect. Reviewing your notes for next items now.

[jimjeffers]

@PropGit I wanted to chat with you shortly about breaking the interactive up into parts before I did so. There is no interactive because it's grown too large for the sharing API provided by framer.

[jimjeffers]

@PropGit Notes from our discussion today:

File Switching Done.

• Jeff to provide alternate screenshot of code to provide interactive demo of file switching. Done.

Syntax Error: Done.

• Syntax error would be below the screen. Correction - my thought was not practical here. This idea may work for mobile, but not for larger screen sizes without having to use much longer source - plus, the error toast would be on-screen all the time (depending on how it was handled in the interactive). This really calls for the solution below. Done.
• Jeff to provide full screenshot of code with w/ or w/o syntax error so that we can toggle the error on and off in demo. Done.
• Jeff provided the above two screenshots (same bad code, one without error highlighted and the other with the error highlighted). Interactive should show the no highlight code first, along with a warning checkmark icon in place of the normal run icon, and upon selecting the warning checkmark, the highlight code example (and error toast) is shown. __Done.
  • Please extract the error toast to display as it's own element so that scrolling the source will not scroll the error toast. Done.

Import / Export Done.

• Could be a single or multiple files. Jeff says: we will limit multiple files to being the selection of a single project (which contains multiple files).
• Share option on context and project drawer.
• Import on project drawer.
• Jeff to mull on the idea of third option for import.

Project Drawer Done. Nothing to change.

• Deciding to leave project drawer as is - do not make it accessible from the code view.

Debug Console Done.

• Add Swipe down. Done.
• Add ability to have console and code view visible at the same time. ~~Dismiss if the keyboard activates. Update, see note below If keyboard is present keep current behavior of forcing one view or the other. Done.
  • Correction - activation of keyboard can occur upon taping in code editor, or tapping in transmit page of Debug Terminal. If code editor tapped, keyboard can appear and Debug Terminal should disappear. If transmit pane tapped, keyboard can appear and Debug Terminal can resize and push to the top of screen above it (hiding code editor). Done.
  • Add transmit pane. Current interactive only shows receive pane. See "Debug Terminal" in Next Design Elements. Done.

Landscape Orientation Done.

• Still mockup of code view in landscape Done.
• Still mockup of the file navigator in landscape Done.

Directives

• Present them as normal code.
• Perhaps do something like intelli-j for suggestions (light bulb icon)
• Best to demonstrate this as a new file interactive. If we use the top of code approach, then we can default to having these items visible as helper tools ABOVE the source code.
• It should default to the most commonly used setting which is {$STAMP BS2} and {$PBASIC 2.5}

Find / Replace Done.

• Google docs examples provided by Jeff. Done.
• Doesn’t quite have enough options.
• Search by matching the case, partial, or whole word.
• Show a demonstration of XCode’s solution to find and replace. Done. *Code highlighting already implemented in main app so focus is on the dialog itself.

Google Drive (process management) Done.

• Jim to add a google doc with a notes about specific interactive and links to the demo and associated screencast. This will serve as a central reference for dev and edu teams. Done.
• Jim to also continue to provide comments w/ links to interactive demos / screencasts on issue 318. Done.