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