nelsonni / bonsai Goto Github PK

When creating a new card, a menu should provide options to either create a Text Editor or Sketch type of Card. The Sketch type should include an area within the card content that allows for sketching via mouse movements. A basic set of color options (black, red, green, blue) should be presented in color bubbles in the bottom right-hand corner that appear when mousing over the sketch area, and disappearing after a brief time-out window after the mouse is outside of the sketch area of the card.

The following functionality for individual stack elements should have unit tests to validate:

• Two cards with close enough position values (both x and y) will result in a stack being created.
• Dragging a card onto a stack should result in that card becoming a member of that stack.
• Newly added cards in a stack should be the top card on the stack; have the highest z-axis value.
• Dragging a card away from a stack should result in that card no longer being a member of that stack.
• Dragging a stack changes the corresponding position values (both x and y) of the stack.
• Calling the expansion button should result in the cards in the stack having new position values (both x and y).
• Calling the expansion button when a stack is near an edge should result in some cards having updated position values, while others remain in a stack.

To replicate this issue, follow these steps:

1. Spawn a Sketch card.
2. Switch to any face other than the first face.
3. Make sketch marks on the content canvas of the card.
4. Switch to erasing mode and select a line to erase.
5. Observe that the card begins swiping back to the first face.

Expected: Sketch cards should allow users to add and erase sketch lines on a single face without triggering a swipe action.

To replicate this issue, follow these steps:

1. Spawn a Text card.
2. Click on the content area of the card.
3. Observe that text field is not selected and enabled for editing.

Expected: Clicking on the content area of a Text card should result in the text field of that face being selected and the ability to type text into the field should be enabled.

A switch on the canvas (located near the buttons) should enable the ability to sketch and add text fields on the background of the canvas. This sketching/annotating should be allowed on all areas of the canvas (except on top of buttons and switches), and Card and Stack objects should be ignored; i.e. a user can sketch/annotate on the canvas behind a card even though the card is currently blocking visibility to that portion of the canvas.

The switch to enable this mode should follow this mockup:

Additionally, when in this canvas sketch/annotate mode there should be four buttons available in the bottom right-hand corner of the canvas:

1. Sketch button which is the default selection when this mode is enabled.
2. Annotate button which switches to allowing text fields to be placed on the canvas.
3. Snapshot button which pulls all of the current canvas sketches and annotations into a new Sketch type card that is placed on the canvas.
4. Clear button which clears all previously added sketches and annotations from the canvas.

The Ace Editor library used for the Code Editor card type provides hover tooltips when working on JavaScript, CoffeeScript, CSS, or XQuery code. However, these tooltips currently float on top of the editor window but below the edge of the card face, for example:

These tooltips need to hover above the card and extend beyond the edge of the card if necessary in order to be readable.

The following interactions should have tests to validate:

• A stack moved close to another stack should result in a single stack with the dragged stack being on top of the stationary stack.
• A stack moved close to an individual card should result in the card being added to the back of the stack.
• A card that has been swiped (or reversed) and then dragged onto a stack should be added to the stack with the primary face showing.
• Combing two stacks that both contain annotations should result in the bottom stacks annotations being appended to the top stacks annotations (and cut at the maximum character limit).

• Cards should maintain similar shape to regular poker cards (height: 3.5", width: 2.5"), thus a 7:5 aspect ratio.
• Cards should contain a top header bar which is the draggable area for the entire card. The top bar should also contain a button for removing that particular card from the workspace.
• For a basic code viewing card, the main area of the card should be a text area that displays text and allows it to be edited. Clicking on this area should not allow a draggable interaction for the card.

Design sketch (for reference):

The last face on any Card instance, regardless of type, should be a non-editable face that contains the metadata fields introduced in #23 and #45. Specifically:

this.creation_timestamp
this.interaction_timestamp
this.creator

Since the this.interaction_timestamp updates regularly, these fields should always be accurate. Thus, the text should always update when a new value has been set for any of these metadata fields.

A white box appears in the upper left-hand corner of card title bars when moving around and working with multiple cards. Not specific to any type of card. To replicate this issue, follow these steps:

1. Spawn two or more cards.
2. Move those cards around and edit the content.
3. Observe the appearance of a white ghosting box on the edited card.

Expected: Cards without random ghosting elements appearing.

Users should be able to draw a selection circle around a set of Card and Stack elements and have them associated together into a group. This group should not alter the position of the selected elements, but should be visible with a dashed line for the border of the selected area. All selected Card elements should have their div.card.highlight CSS rule enabled. Card and Stack elements not within the selection area by at least 75% should not be included in the selection.

Lasso selection mode should be enabled and available at all times, except when Canvas Sketching/Annotations are enabled (see issue #36 for details about the slide switch that enables canvas sketching). Once the mousedown event is detected on the canvas (not on top of a Card or Stack element), the lasso selection should begin and continue until the mouseup event has been detected, at which point the selection should be completed. If there is a gap between the ending position and the starting position, a straight line should be drawn between the two points to complete the selection area.

Mockup of the proposed concept:

Additional option from the menu should be a Code Editor type of Card. The Code Editor type should provide line numbers, syntax highlighting, the ability to edit code, and a basic undo feature for code typed into the card.

An initial mockup for the card is as follows:

Cards should have two faces:

• Front-face for the primary content of the card (e.g. code for editor, graphic for design, text for documentation)
• Back-face for meta-information related to the card itself (creation timestamp & username, last interaction timestamp & username)

To change between faces, a reverse button should appear in the lower right-hand corner of the card when the card is in focus and hovered over. Design sketch (for reference):

The UX for flipping the card between faces should follow this example of the flip motion (the burst animation around the mouse location when clicked is not needed):

With the increased number of CSS and JS files related to the different Card, Stack, and individual card types, the index.html file has become blotted with <script> and <link> tags to pull them all into the application. These can be offloaded to a function that dynamically adds them instead.

Moving cards within the stack causes the cards to misaligned within the stack container.
Also, when the cards are deleted while stacked, the stack container does not disappear.

The JetBrain's documentation for the IntelliJ Platform indicates that certain portions of the .idea folder can and should be checked into VCS in order to allow project sharing between developers source. However, this project does not require the use of any of the IDEs developed by JetBrains in order to contribute to this project.

Therefore, the .idea folder should be untracked from git and removed via a future commit. And to prevent future commits from accidentally including the .idea folder, a rule to exclude the directory should be added to the .gitignore file.

Centering cards in stack isn't working on Windows.

Travis CI service should be enabled and added to the project. Once this is enabled, all QUnit integration and unit tests should execute upon the creation of a Pull Request.

The Card class currently has checks for Sketch and Editor type card in order to drive different behavior based upon the specific card type. This violates the Object-Oriented Programming (OOP) principals of encapsulation and separation of concerns.

Instead, all card types should be classes that extend from the Card class and pass a specific faces constructor method into the parent Card class in order to build the content area for each card. Any violations of these OOP principals should similarly be provisioned into the appropriate child classes.

For example, the method js/cards.js::buildFaces() contains:

if (type === "editor")
  $([face1_editor, face2_editor, face3_editor]).each(function (idx) {
    $(this).attr({
      id: card.id + "textEditor_" + idx, class: "editor"
    });
  });
else if (type === "sketch")
  $([face1_editor, face2_editor, face3_editor]).each(function (idx) {
    $(this).attr({class: "sketchEditor", id: card.id + "sketch_" + idx});
   });

Update the code structure within both cards.js and stacks.js to take advantage of JavaScript classes that are provided in the ECMA-262 standard that describes API capabilities for JavaScript ECMAScript 6 (ES6). This also allows object-oriented design to be imposed upon cards and stacks, and any future work that builds upon them.

The following functionality for individual card elements should have unit tests to validate:

• Opening a card creates a new card, which increases the number of cards on the canvas.
• Closing a card removes that specific card, which decreases the number of cards on the canvas.
• Dragging a card changes the corresponding position values (both x and y).
• Selecting the top bar section of a card should result in a draggable selection.
• Selecting the content section of a card should result in an editable field being selected.

Workspaces will contain an unknown quantity of containers ('cards'), therefore the initial requirements for these containers are:

• Dynamic instantiation
• Indexable
• Draggable

This will be accomplished through JQuery (reference: https://jqueryui.com/draggable/).

Currently cards can be dragged anywhere within the workspace window, which can lead to situations in which the draggable top bar is moved outside of the viewable window and becomes inaccessible. Cards should be restricted from being moved outside of the boundary of the workspace window in order to prevent this issue. This will also impact stacks of cards since they shouldn't wander outside of the boundary of the workspace window either.

Cards should maintain the following metadata fields:

• Creation Timestamp: Contains the date and time that the card was created.
• Interaction Timestamp: Contains the date and time that the card content was last interacted with (clicked into and altered in some way).
• Creator: Contains the username that created the card (a placeholder of USER is fine for now).

These three fields should be displayed on the metadata face of the card, which is required to exist for every card. This information should be presented in a read-only manner that prevents alteration except through interactions that update the information in those fields.

Dragging

• With a 2 text card stack, after the first drag, the editor doesn't allow for the stack to be dragged anymore. Instead It only allows for text entry inside the editor.
• With a 2 sketch card stack, dragging across the editor also causes the underlying sketch card to be activated.
• When a card is expanded inside a stack dragging on the text area causes the stack to have all the cards aligned plus the one card still expanded to full screen
• Upon dragging a border of the highlight box typically disappears
• Three cards spawned consecutively, when dragging top spawned card onto stack causes two stacks to appear. The 3 & 2 card in one stack, and the 1 card in it's own stack.

Inter-actability

• Creating consecutive spawned cards stack directly on top of one another, not allowing user to see what they have spawned.
• With a 2 text card stack, clicking at the bottom of the stack brings up a text entry box and doesn't allow for dragging.
• Cards in a stack are still editable (Thought they were supposed be disabled)
• Deleting a card in a stack doesn't cause the highlight box to resize.
• Deleting the 2nd to last card of a stack causes the highlight box to still be there.

Double stacks

• Dragging a stack of 2 cards onto another stack of 2 cards causes the two highlight boxes to remain, and shuffles card order.
• Dragging a stack of 2 cards onto a single card causes 2 highlight boxes to appear instead of merging them

Stacks of cards should provide a feature that expands all cards in the stack into their individual cards (i.e. from stacked to unstacked). This feature is not required when viewing and editing cards, therefore it should only be a visible option when hovering over a card stack.

Design sketch (for reference):

The Stack elements should allow for a brief 80-character annotation to be typed into the bottom right corner of the selection area border that surrounds the cards within a Stack. This annotation should be deleted when a Stack is dissolved (via pulling all Card elements out of the Stack).

To replicate this issue, follow these steps:

1. Spawn three consecutive cards of any type. Do not move any of the cards from the spawn point.
2. Drag the top card onto the card immediately below it.
3. Observe that cards 2 and 3 are added to a stack, and card 1 (top) is added to a different stack.

Expected: Card stacking near the spawn point should disabled, and stacking multiple cards in the same area should result in a single stack being created to contain all cards in the vicinity of the dragged/dropped card pair that initiates the stack instantiation.

Any Sketch card that has a background image loaded (via file opening), and is then set onto a stack will immediately switch the background back to a default color background.

To replicate this issue, follow these steps:

1. Spawn a few cards and stack them together.
2. Using the Open... menu, load an image into a new Sketch card.
3. Drag the Sketch card onto the stack of cards.
4. Observe that the background image is gone and the card never shows it again.

Expected: Cards should not be altered when being added, or removed, from a stack. The background image of a Sketch card should remain even when added to a stack.

The basic requirements for stack expansion remain the same as illustrated in #4. However, since then it has come to light that there is a literal edge case for this functionality. When a stack would normally expand beyond the edge of the canvas, the stack must instead only partially expand in order to prevent cards from being occluded.

To proper avoidance behavior is to emulate the act of dealing from a deck of playing cards. A card is removed from the top of the stack and placed on it's own in the expanding area. This process is repeated, and as a new card is removed from the top it is set down nearest the stack. This will cause the previous card in that position to one card position farther from the stack. This process continues until either all cards are fully expanded from the stack, or the edge has been reached. The following illustration demonstrates this design:

The slider arrows and dots displayed on Card elements to indicate additional faces for individual cards should hide except when in focus or hovered upon. Requirements:

1. When the content of the current face is in focus (i.e. has the cursor captured), the arrows and dots should be visible.
2. When the card is hovered over, the arrows and dots should be visible. When the card is no longer hovered over, the arrows and dots should stay visible for an additional 0.5-1.0 second (whichever feels more natural).
3. When the card is in a stack, the dots and arrows should not be visible and should not enable on hover.

This is an initial feature, with additional auto-saving features forthcoming in later versions.

When working with Card elements that were generated via opening a file (or folder), any changes made to the content should be immediately saved to the same loaded file. Since this feature could potentially be an interaction blocking behavior, this saving functionality should occur in the background. Thus, this feature requires multithreaded processing to take place within the IDE. There should be a visual indicator that the file is saving, via the cursor: progress CSS option when the mouse hovers over the particular card that is saving.

When multiple cards are open on the workspace, the currently selected card should be brought to the foreground and all other cards should have lower Z-index values than the currently selected card. This foreground/background focus feature should allow users to organize cards in the Z-axis such that selecting multiple cards in sequence results in those cards having a similar Z-index value sequence (i.e. the oldest interacted card should be at the back, the latest interacted card should be at the front).

To replicate this issue, follow these steps:

1. Spawn a Text card.
2. Select the fullscreen button for that card.
3. Observe that the text field area within the card content does not scale to the larger container size.

Expected: Users should be able to view more of the content, or work with a larger empty text space, when in fullscreen mode.

Using the shaping matching functionalities provided by kjkjava/Sketchy.js, provide a 0-100% heuristic of the similarity between two Sketch cards that are placed side-by-side. This feature should be enabled via a context menu when the two Sketch cards are placed side-by-side.

When a file is imported into a card, the title of the card (which currently reads Card: 1, Card: 2, etc.) should update to reflect the name of the file. For example, if I open ../tests/js/qunit.js using the Open... button then the card that is created should have the title updated to be qunit.js.

This feature should not remove the ID number of the card, but simply swap the information presented at the top of the card to reflect the filename instead. When a new card is created from within the IDE, but not via file importing, the original behavior of indicating Card: 1 information should continue to be used.

The previously described Open button (see Issue #34) should be enhanced to handle opening and loading multiple files into multiple cards via folder selection. When a folder is selected, all files in that folder that can be loaded should be individually loaded into the appropriate card types. Those files in the folder that cannot be loaded should trigger a popup message (only one notice per folder importing) which indicates the filenames and a count of those files that could not be loaded.

An Open button at the top of the canvas should allow users to browse their local filesystem and select any of the following files for opening:

• Files with extensions that map to any of the 110 programming languages that AceEditor supports should load into a Code Editor card.
• Files with no extension or a .txt should load into a Text card.
• Files with image extensions (.png, .jpg, .gif, .webp, etc.) should load into a Sketch card.
• For all other files with unknown/unsupported extensions, a popup message should let the user know that the selected file cannot be loaded into the IDE.

Cards should have 2..n faces which can be accessed via a swiping motion across an individual card. Since this motion might not always be intuitive to new users, cards should provide a visual indicator when the mouse is near a side of the card that can be swiped. The content of the different card faces is irrelevant to this issue (i.e. content representations on different faces will appear in other issues).

The following type of bubble icons should be added below each card as a visual indicator of the number of card faces available, the directions those additional faces exist, and visual feedback regarding the current card face position in the carousel of faces:

The minimum number of card faces will be 2 (content face and metadata face), so no matter what each card will have the swipe interaction enabled. When cards are placed in a stack, however, this interaction should be disabled.

This is a radical diversion from the card flip interaction previously added in v0.2.0. Therefore, to explore both interactions we should have a switch button to change between the flip and carousel interactions. This button should reside near the Create Card button at the top of the canvas, and appear similar to the following:

Since content within each card will quickly overflow the available viewing space, cards will need a mechanism to expand so that content can be examined using a larger portion of the screen. Next to the card deletion button in the top bar, a new button that expands and shrinks cards should exist. When pressing the button on an individual card, the contents should expand to the entire window. If already expanding, the button should shrink back down to the card size.

Design sketch (for reference):

The UX for expanding the card should follow this example of the transform motion (the shape change is not needed):

Content is moveable and mixable, so therefore a mechanism should allow for card creation when users are working with other cards.

• For Code Editor and Text cards, selecting code/text should provide a hovering context menu that allows a new card to be created to contain that snippet of code/text. The appropriate card type should be created based upon the card the card that contains the selection (i.e. selections from Code Editor cards should create Code Editor cards).
• For Sketch cards, a button should allow the user to select a specific portion of the sketch face and export it to a new Sketch card.

Cards must be able to be selected, dragged, and dropped onto other cards to form stacks. Selecting the visible area of a single card in the stack and dragging away from the stack should allow that card to be removed from this grouping. When in a stack, the stack of cards should be draggable when selecting any of the visible portions of the top header of the cards.

Design sketch (for reference):

Bugs found regarding a singular card

Sketching

• Erasing a sketch mark on a card causes the card to swipe back to the first card.

Swiping

• Arrows for indicating a swipe are found on the sides but are un-clickable
• Text fields on the card are un-editable upon spawn until swiped to a different face.

Fullscreen

• Upon expanding into full screen the text box doesn't scale full screen with the card.
• Collapsing a fullscreen card causes the dots on the bottom, and the arrows on the side to disappear and never reappear