I think it would be more reassuring to the user if a notification popped up confirming that the default frame directory has indeed been changed after the "set as default directory" button is pressed.

While this is mainly my issue, since I redesigned the entire Onion Skinning slider, I thought I'd bring it up so we can discuss it. Basically, as it is, the onion skinning slider isn't very easy to understand. It is in the middle, and you can drag it up and down to change the onion skinning factor, but it only takes effect if the Onion Skinning button is enabled. The button and slider act awkwardly together, and it's not really easy to understand what each is at first glance.

So, I am thinking we need to find a way to get rid of the button and use the slider exclusively. One way to do this is to make the onion slider be at the bottom of the slider by default, and when you drag it up and down, it adjusts the opacity. This removes the need for a separate onion skinning button, but it makes the slider look off-balance with everything, since the circle isn't in the middle.

Another way to do it is to make the left and right portions of the slider do different things. It works like this in Dragonframe:

• Drag to the right: Onion skins last frame taken with live preview. If you select another frame, it doesn't show any live preview or onion skinning.
• Drag to the left: Onion skins last frame taken with live preview if on live mode. If you select another frame in the reel, it'll use that for onion skinning instead.

We don't have to do it like this, I'm just unsure what we need to do. Eliminating a need for a separate button would help a lot.
What do you guys think?

This was a major bug that I accidentally created with 26a47ba

It should follow the same design as the animator.

This will be easier to add, I'll probably do it myself. Basically, it's just an SVG grid that overlays over the video showing the rule of thirds on top of the live view.

Legoguy501 on Bricks in Motion also suggested this interesting feature. An option to specify a controller/utility program (such as Logitech Webcam Controller) to open on launching a new project could be very handy. In addition for known applications the animator window could resize to fit the controller

Scrolling beyond the first or last frame results in a buggy ui. Also the slider below the captured frames and the delete icons do not currently function.

When switching between live preview and frame preview, this is a bit of lag-time where nothing is shown in the frame-space. There needs to be some type of placeholder div (with the same responsiveness as the video and frame boxes) to hold the place of the frame so the interface doesn't break while switching.

I'm sure this will be long in the future of Boats Animator, but I thought I'd mention it now anyway. In short, I'd like theme support. I've been thinking a lot on how to do this, and here's my solution:

-For your program CSS, you'll have to do a bit of re-working. You'll have your normal style.css witch has positioning and all (but not colors), but you'll also have a default-theme.css that contains ONLY colors. This will be compiled into the program and cannot be directly edited by the end-user.

-You have a folder called Themes which the user can view and edit. Inside this folder is a template, which is basically a duplicate of default-theme.css. The user can make a copy of the template, rename it, and change the colors inside to design their own themes (you could also package a couple themes inside the program itself).
In your code, you would have something that scans the folder on program start and looks for theme files. If they are present, it reads the header of the theme file (mentioned below) to collect the name of the theme. It then lists the themes in the settings menu for the user to change at will. These themes basically just overwrite the default css colors of the program.

Here's an example of what a theme css could look like:

/*
---------------
ThemeName: "Example Name"
ThemeAuthor: "Example Author"
---------------
*/

body {
background-color: blue;
}

.sidebar {
color: white;
background-color: black;
}

Themes would be great, then we could change between dark themes, light themes, and any theme we want.

This is due to them not always lining up with the edge of their respective windows. This might not look so bad if the input video was 16:9. On a related note I need to start working on the ability to change video resolutions because I am yet to consider the effect of 16:9 aspect ratios on the interface.

When you delete a frame from within Boats Animator, it deletes it from the files and still seamlessly plays back the frames in-program. This is fantastic. However, when you try to import those frames into a video editing program as a video sequence, it will break on the missing frame (for example, IMG_0001, deleted IMG_0002, it can't get past 0001).

Thus, if you add a button in the file menu called "Confirm Take", it will just fix the image sequence by renaming all the pictures in the sequence to be sequential once again. However, this will be different than "Save Project", for someone may not want to confirm the take every time they same the project (there are various reasons for this).

Alert boxes look very intrusive at the time being, not really matching the program. I was thinking that they could be converted into notifications with buttons on them (Notifications that don't go away until you click on it).

Either that or Alert boxes need better styling.

This bug comes from the quite horrid current method of determining the height of the preview area.

There are a number of error and success messages that ought to be displayed to the user. However, an alert() box creates a bad UX. What we need is a simple, elegant, unobtrusive system to display the messages.

We have two options:

1. The HTML5 Notifications API. It is simple and works well, but it looks different everywhere, can't be styled, and you cannot denote what type of message (success, general, error) is being displayed.
2. Roll our own, which is not that hard at all. There could be a div hidden at the top of the screen. When triggered, it will appear for a short bit to display the message and go away automatically. We can have 3 APIs: success, general, and warning. Each one can apply styling specific to the error type (success green, general blue, error red).

I am leaning more towards rolling our own for customization purposes, but I'll leave it up to you which should be used.

The previous frame rate should be used if cancel is pressed. A method to ensure only integers are entered should also be added.

I'll explain soon, but tl;dr it is 100% wrong. I've researched this and gained some info on it, and that's not how it's done.

Later on, we can add an aspect ratio option that puts a mask over your video (with a slider for transparency) depending on the aspect ratio you set. On video export, an option would be there so you could crop your video based on the mask, but raw frames would not actually be cropped with the mask, the mask would be purely visual in the program.

Since #38's redesign of the frame reel features a scroll bar which has arrows performing a duplicate function I think the current large black ones should be removed.

Currently, when you load the launcher, and you click the New Project button, it simply resizes the launcher window and changes the content. This is bad because, 1) it has the "File, Edit, Capture, Help" menus on the launcher, which don't do anything there, 2) it causes problems later when projects are implemented, the animator window doesn't just need to change to a launcher, it should load a new launcher window (and vise versa), 3) the window looks crazy while it is switching between programs

2d4d8f0 brings the ability to choose output resolutions, however at higher resolutions playback performance is horrendous.

One way to potentially combat this is for a low res "shadow" version of each captured frame to be generated and saved to temp storage for use in the frame reel and for playback.

Alternatively I suppose this issue could be fixed with an improved method of playback. My understanding is that @le717 will be working on this.

I have a feeling that the best way to combat this issue is probably a combination of the 2 things mentioned above.

Not that this is priority at all, or even necessary, but it's something that I thought I'd mention anyway. In my opinion, there should only be one box that displays frames. Basically, combine the live preview and the playback boxes. This makes the interface simpler and more streamlined. It would work a lot like Dragonframe. Here's how:

On the right side of the frame timeline (at the bottom), there is a "Live Preview" button stuck there (the horizontal scroll-bar doesn't affect it). If someone clicks on a previously captured frame, it will preview that frame instead of the live frame. Playing the video will do the same thing, it just covers up the live frame. When someone clicks the Live Preview button, it will get rid of the playing video or the previewing frame, and show the live view again, onion skinning and all.

Of course this is just personal preference, but to me it seems quite logical, instead of having two preview boxes.

We really don't need it in there, plus it makes upgrades, (un)installation, and shortcuts easier to do. :)

Legoguy501 on Bricks in Motion made some good points to me about the frame rate chooser's behaviour, I thought I'd reiterate them here:

• Add a maximum to the frame rate. Currently, I can enter a frame rate of basically infinity.
• Make the frame rate reset to 15 or default to 1 if it gets deleted. Currently, it becomes infinity.

If an output folder is set but does not actually exist, the path should be created and the user notified (use notifyInfo()) so frames can be saved/deleted.

Obviously this is something that isn't at all a priority, but for the best user experience on Windows the program should eventually be available in the form of an installer. I've been looking at a couple of solutions with Inno Setup being very easier to implement but limited in features and Advanced Installer being very powerful indeed!

Advanced Installer is usually pretty pricey but they appear to offer free licenses for open source projects. I've been playing playing around with the program's trial and am quite impressed. This seems like a feature that would really give Boats Animator a professional touch. Is there any obvious reason why I should not get in touch with them for a license?

The main reason I could see against doing this is a question of the necessity of an installer.

When one clicks a frame in the framereel, it needs to show up in the preview box. It also needs to have a little border around the icon in the framereel so the user knows what frame they currently have selected.

In the StatusBar, the "Current frame" also needs to reflect the frame that is currently selected.

Ran the source in an Ubuntu virtual machine to see how BA appeared. For reason the menu icons appear full size rather than resizing like they do in Windows. The current menu icons need changing to match the FontAwesome ones anyway.

I guess the solution would be for small icons that aren't resized to be displayed for Linux users.

Feature Roadmap on Google Docs

I see you have been revising the roadmap but it only accounts for the major features. Further, we need something more incremental to go on to guide us one release at a time. So this morning I drew this up (I will have to transcribe it later):

Red means high priority, green medium, and blue low. Basically, it would guide us through each release, mapping out the currently known plans (as well as ones yet to be filed) and when they would be fixed/implemented. After 0.8.0 things started getting vague and I did not get the time to finish planning it out.

You will notice that the low priority listings for 0.7.0 and 0.8.0 became the next release high priority points. I did this to help gear the work towards the next major milestone. Initial work would begin on a branch sometime while that release was being developed. This branch (or even many branches trying out different ways of doing things) would ideally be cut from the last tagged commit and not updated with master changes in order to have it focus solely on the intended feature. It could then go through code review and planning as it was being developed. Then, when the release the feature is slated to be released in came around, the (best) branch would receive the main focus, getting prepped up and merged with master so it would be ready for it's debut.

I also tried to keep major changes to their own releases. Projects will be huge, so it gets 0.7.0. Resolution/camera gets 0.8.0. Takes get 0.9.0, etc.

Obviously this is all an idea, out of date (I think you may have solved the vague 0.9.0/1.0.0 releases...) and up for discussion, and smaller items could be released in patch updates (e.g., 0.6.1) but I am throwing it out here anyway because we need a plan. :P

I downloaded NW.js to run the program in it, when I realized there is no app.nw file like the readme says to open.

This is an issue for way later. FontAwesome is currently pulling from the web, so the icons won't appear on offline testing. Once we get all the icons we need, we'll need to build a custom package of fontawesome and upload it to the repo to be packaged with the program.

Of course, if you chose not to use FontAwesome, then this doesn't specifically apply, but it will apply if you chose to use any other icon font. ;)

On the splash screen, when you click the Charlielee.uk link, it opens a new Boats Animator window to load the website. This isn't good practice, because then someone cannot bookmark it and stuff like they would in a web browser. It should open the link in the default web browser instead.

Another nit-pick I have is the new splash screen. I like how you have news and stuff, but it's annoying that it has a scroll bar, but there's a big blue space on the left side. I think that the news should probably be inside the blue sidebar. It will separate Project Tools from the News, and make the entire thing easier to use. The less scroll bars the better, IMO. ;)

• The live view button should not toggle between live and preview. When a frame on the framereel is selected, it will go to the preview frame, but if the live view button is selected, it will go to the live view.
• When the user is on live view mode, the live view icon needs to have a border around it, similar to that of when a frame is selected on the framereel.
• The live view button is currently on the left side of the framereel, when it needs to be on the right, just like a frame on the framereel, it scrolls.
• The live view button is also the wrong size, for some reason.
• The Live View button also needs a hover-title so people know what the button is.

Of course, this depends on if you keep the live view button the way it is. You mentioned you didn't think it was very good, but maybe it just needs a bit of help? We can discuss this. ;)

Edited by BoatsAreRockable to make the bullet points into check boxes

This element in the sidebar is currently too high

I think that Boats Animator should start Fullscreen on first load. While this is personal preference, it's actually much more logical. Animators want to see the frame preview as large as they possibly can, and if it starts fullscreen, it will simply make it easier to use, instead of having to fullscreen it every time/

If a notification is shown, and another comes up, it overwrites the current notification. There should either be a window for the notification list, or the notifications can stack on top of each other so when one goes away (maybe by clicking on it?), the other is shown.

Something that really should be implemented!

When the program is opened, a splash screen is seen for a second, not enough time to read. Then, it opens up to the project manager box, which says the same thing as the splash screen (the name and the creator), along with other stuff. I think the first splash screen should be removed in order to save time, and because it really isn't needed, seeing as all of it's information is already seen on the next screen.

I just realized #3 lost your chosen button styling. I'll get right onto fixing it ASAP. Sorry about that. :(

This isn't really an issue, but I think it needs to be brought up. You, Boats, can push commits directly to the master branch. Contributors working on forks cannot commit to the master. We have to submit pull requests. In my opinion (and I think this is actually a good practice of using Git), you should create branches, edit on those branches and submit pull requests. Then you can push them to the main. This way, contributors have a bit of time to see the commits you are making without having to change their code every time you make a commit, and they can make their changes uniform with yours a bit later, before they make a pull request. This also permits code and design review to see if everything works and acts well (especially review by other contributors).

In short, the master should be a cleaner, more stable branch, and branches are unstable WIP things. Of course, some small things can still be merged into master without pull requests, but large things like custom scrollbars, or custom resolution, should be made on a separate branch and submitted with a pull request.

It just helps everyone around. 😉

The saved frames from the program are labeled by the date and time, in fact, it sets the time as the time I opened the program (for example, if I opened it at 12:30, and took frame at 2:45, it would still label the frames as 12:30), instead of setting it every time a frame is taken. However, I think the program should number the frames by sequence, for example, ProjectName_0001. This will help with organization and image sequencing.

This appears to be a new issue that occurs after clicking "New project" on the menu screen. Normally the main animator window becomes larger upon opening it.

I've been looking in the files, and I see you are using various PNG files for the in-program icons. I was thinking that we might want to consider using FontAwesome for these instead, because it is much more flexable than images.

For example, it only has to load the font once, it acts like text so you can color scale and such easily, and it is actually probably smaller in file size than png images. There's even a few animated icons for loaders and such.

Though, this is just personal preference. It might make it where you cannot add icons in the menu bar, so that's a minus. I was just curious what you thought about that.

Here's their website:
https://fortawesome.github.io/Font-Awesome/icons/

Alternatively, we can use the .SVG versions of the icons from flaticon, which will allow a bit more ease for scaling the images. Either way, we do need to not use PNG files, we should be using vectors or a font. ;)

CSS-Tricks has an excellent article on how to do this.

#38 removed the onion skinning overlay. @le717 has said it this will be fixed so I've created this issue just to keep track of that.

Currently (C) Charlie Lee 2015 is displayed in both the animator and menu windows. I have a 2 part question regarding this:

1. Is it standard for this information to be prominent in such a way, would it be better for it to be displayed in the menu window, not at all or on a separate about page?

2. Boats Animator is an open source project and this copyright attribution was added before I created this GitHub repository. Since there have been major contributions by others is saying that the program is Copyright Charlie Lee strictly no longer true and a bit inconsiderate to the other contributors?

Obviously this is an issue that would potentially be slightly awkward for anyone other than myself to bring up but I really want to make sure that I'm doing things properly and that the current and future contributors to BA get the credit they deserve.

The Play Animation and Pause Animation buttons are separated. They should be combined. When you click play, it will turn into the pause button, so if you click it again, it will turn back into the play button. This helps for easy pausing when playing back an animation, because you don't have to move your mouse.

When I change my saved files location, and I click "Set Default Location", it should ask me to confirm that. It's quite easy to accidentally click the button, and I don't necessarily want to change my default location every time I click it.

There are two rules you always need to follow:

1. Never call it simply "Setup"
2. Always include the version number.

@le717 mentions fixing this in #22 but I feel it would be a good idea for this to be documented as a separate issue due to its importance.