doodle3d / doodle3d-client Goto Github PK

Right now if you cancel a Doodle3D print the printer homes X/Y and nothing else. On the UM2 this means you potentially hit the clips that hold the glass plate in place. It is better to retract a bit, and move the head up (bed down) a few mm. This also gives less chance that your doodle will stick to the nozzle.

Maybe we could start the progress indicator at say 5% to clarify it's a progress indicator and we are printing.

Currently when you press the settings page the window is opened and settings are loaded. So on slower devices or a bad connection you might see empty settings for a (scary) moment.
We should probably start loading when you press the settings button and open the window when this was successful.

Firefox mobile is rendering many grey areas throughout the interface. Haven't seen that before, could it be an artifact of the jquery joyride plugin?

Should we add a "reset" or "revert to defaults" to the settings window?
When the printer behaves weird or in situations where a lot of people have access to the settings dialog you might want to revert the settings their defaults.

Should we incorporate updating the firmware or more hints about it into the tour the first few times the device is used? (Not the first few time a new client visits the client)

The color of the thermometer only goes up to the target temperature, but never beyond. So when it's warmer than the target temperature it looks like it's at the target temperature.

The move up/down and twist left/right buttons aren't spaced well in the mobile view. The buttons work, but the buttons aren't spaced naturally between the doodle area and the bottom of the browser

Settings: Celcius / fahrenheit

Add Ultimaker2 to printer type list

Should we add a handy download debug logfiles button?

At the moment you can download logfiles on url:
currenturl/d3dapi/info/logfiles

Maybe add this to a debug section in the settings window?

In some cases we use an native alert() for warnings, like your drawing is too complex. It would be nicer to use a custom styled modal popup.

the local 404 page could be a very helpful way of telling people the're connected to the box instead of to the internet.

The Message info-bar top-right in the interface disappears after the website tour is finished, even when it shouldn't. This is corrected by the interface as soon as the WiFiBox sends a new status, but of course the tour shouldn't be hiding interface elements that are supposed to be visible.

Currently when you've changed you're mind and you changes settings you can't press cancel.

Currently everyone that's on the same network as your box can reach your box. In some situations you might want to hide it.

An option might be that it doesn't show up in connect.doodle3.com but instead there is also a input field on connect.doodle3.com where you can input the wifibox id that you want to connect to. Only when you type this correctly you are connected to the box

This also requires a hide checkbox in the Client mode settings.

To prevent issues with printers running into their endstops we could limit this scale between 0.1 and 0.5.

There's a way to choose several vertical outlines, which was done quite quickly when we were making builds for the Ultimaker people. Could probably use some reviewing

While buffering (sending the doodle) we added a warning (onbeforeunload) so that when a user tries to close the page they get a warning. It's removed when it finished sending.

This works on desktop chome and safari. But on Firefox it doesn't show our custom warning. This is already filed as bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=588292
Mobile safari (iPad for example) and Opera ignore this completely.

There don't seem to be alternatives.

More info:
https://developer.mozilla.org/en-US/docs/Web/API/window.onbeforeunload?redirectlocale=en-US&redirectslug=DOM%2Fwindow.onbeforeunload

Currently the network settings logic sits in the general SettingsWindow class. This makes it very unclear and complicated.
For further improvements and maintainability we should separate this, like the UpdatePanel.

Firefox puts the outline (css: outline) around the shadow.
Maybe we should switch back to using the regular border?

Adding more and more options to the settings page makes it very cluttered (and scary).
We could implement a system to seperate parts into for example

• Tabs (limited by horizontal space and thus tricky on smaller screens) (http://jqueryui.com/tabs/)
• Vertical tabs (limited by horizontal space and thus tricky on smaller screens) (http://jqueryui.com/tabs/#vertical)
• Sub pages (harder to implement just with javascript)
• Accordion (creates a lot of movements) (http://jqueryui.com/accordion/#collapsible)
• Fold out system (accordion like, but without limiting it to one open panel at the same time. (http://jsfiddle.net/soboaz/3gHrv)

I prefer the last option. Easy to implement with javascript, not limited by horizontal space, less surprising movement like a accordion menu.
http://stackoverflow.com/questions/3479447/jquery-ui-accordion-that-keeps-multiple-sections-open

Consider this use case:

1. Connect to a protected wlan network for the first time
2. Switch to AP mode
3. Switch back to client mode, and select the previously chosen network.
4. Now before clicking 'Connect', you have to enter the passphrase, even though the wifibox already knows it internally.

It would be useful if in this case the password field is prefilled with the correct passphrase, so you can just click 'Connect' after picking the right network.

When using a vertical shape 'cone' with the largest part up, drawing a very small object, the printer will not be able to print the smallest part.

Currently to give a bit of feedback the settings window closes only when the settings have bin successfully saved. But this does mean you can keep pressing the button and overload the webserver on the box.

This is partly related to the following issue:
Doodle3D/doodle3d-firmware#11

We should disable the button on save and enable it again when it has received an response or failed.

At the moment you can enable bed temperatures by changing the following line from the start gcode (found in the settings).

;M190 S{printingBedTemp} ;set target bed temperature

To:

M190 S{printingBedTemp} ;set target bed temperature

And the following following in the end gcode:

;M140 S{preheatBedTemp}

To:

M140 S{preheatBedTemp}

Basically you uncomment by removing the ; at the beginning of the line.

Would be nice to enable or disable bed support with a single checkbox... But how to combine that with the start and end gcode fields?

Currently there is no way to do the following things:

• Download saved doodles
• Remove saved sketches
• Have an overview of saved sketches

We could add a Saved doodles section in the Settings window for this.
This could show a list with all the saved sketches and per sketch:

• Small preview
• Download button
• Remove button
• Maybe a date?

This does require some kind of tabs/paging system, see issue #22.

It's common UI practise to be able to exit/close a modal popup by pressing escape or clicking outside of the modal popup's area. This isn't the case at the moment, would be an intuitive addition

Because the Makerbot speaks another language we need specific start and end code.

We should try to only show one set at the same time, so or the Marlin codes or the Makerbot codes. We could do this according to the printer selection or a radio button closer to the start end code settings.

Manually draw the doodle outline (its silhouette, if you will)

Having a setting what the initial print height is, as a percentage from the max height.
This is the default height before a user starts tweaking it with the higher / lower buttons.

None of the text in the settings window is selectable. Probably because of an overlaying dom element.

issue, issue, issue

ToDo:

• Prepare one font (convert to simplified svg paths?)
• start wordart button
• Connect letters with a bar
• limit length of input?

Currently when you've changed you're mind and you changes settings you can't press cancel.

Currently the stop button is removed while sending the doodle. This is because of the following issue:
Doodle3D/doodle3d-firmware#16

When we fix that we don't have to bluntly hide the stop button.

When the connection to WiFi box is lost, the buttons for prev/next Doodle aren't functional and should be disabled.

Not all buttons in the Doodle3D interface are disabled/enabled as an honest representation of their availability. For instance the 'oops' button is always enabled, even when there's no draw points to delete.

If the viewport of the app is very wide (most likely to be the case with certain tablets) then the buttons of the left and right panel of the app can disappear off the lower side of the screen.
User can fix this by viewing the app fullscreen. Alternatively we could make the panels less wide (size of buttons will automatically resize) programmatically

When the WiFi box is initially used in accesspoint mode, the tour is shown, but the link to www.doodle3d.ocm/help won't work, because well it's in access point mode.
We should add a local help file that explains how people can access the online help file.
It's actually the first link we show to people when they use the box.

The settings window was disabled during print because some options could cause a print to fail. For example updating would stop a print, or connecting to another network might interrupt sending an print. So to be - better save than sorry - we disable the settings while buffering/printing/stopping.

But there are situations where you want to check the settings that you used while you are printing...

Most options like updating, changing network should be disabled in the API while buffering/printing/stopping so we could enable it again. But this requires some testing.
It also prevents saving settings, since that can't interrupt a print or even sending a print that should probably be reenabled in the API.

When the printer is still cold and you start a print it takes quite a while before it starts printing. Showing very clear feedback that the printer is busy heating might take away some confusion.

We can't easily use the regular status messages (top right) because this is at that moment used to give feedback about buffering. We could make these messages stack, like Crowl on OS X, see the following examples.
http://webtoolkit4.me/2009/08/13/jquery-growl-likenotification-systems/
http://boedesign.com/demos/gritter/
http://plugins.jquery.com/jgrowl/

We could also use another part of the interface, doing something with or around the thermometer.

Implementing this requires good feedback from the printer that's it's actually heating. Currently this isn't communicated. We can see that it's busy at line one, the line of the heatup command in the default start gcode, but this is something users can change.
For Marlin printers this should be quite doable since it returns a very specific kind of temperature while heating. And this is only send went it actually waits for the hot end to reach the target temperature.
We could add this info in the API in the general info/status and in the printer/state as a separate boolean.
It's probably unwise to add this to the current list of possible printer states because you'll get a lot of things that need to happen while in the printing/stopping/buffering/heating state.

We use an offset to print doodles at the center of the printer bed. But this offset depends on the bed dimensions, which vary per printer. So this needs to be configurable.

Because the Makerbot speaks another language we need specific start and end code.

We should try to only show one set at the same time, so or the Marlin codes or the Makerbot codes. We could do this according to the printer selection or a radio button closer to the start end code settings.

It is tempting to save settings per printer type, but this be much more complicated.

For example, when there isn't target temp information yet, the target temp is 0 and because the current value is usually 30 something it's red.