Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile-friendly UI #12

Closed
imitation opened this issue Jan 7, 2013 · 32 comments
Closed

Mobile-friendly UI #12

imitation opened this issue Jan 7, 2013 · 32 comments
Labels
request Feature request

Comments

@imitation
Copy link
Contributor

While the current UI functionally works perfectly on smartphones, it requires frequent zooming and panning (or holding the phone in landscape) to do stuff. An interface with a single column layout and larger buttons would be more suitable for a portrait smartphone.
Lowest priority for me.

@jjg
Copy link

jjg commented Jan 7, 2013

I could see dropping the realtime temp graph (or making it optional) to condense things, especially on mobile. It's neat and helpful when things are funky but generally speaking it seems like a lot of traffic and screen for something I'm hoping my electronics is handling on its own.

@imitation imitation reopened this Jan 7, 2013
@imitation
Copy link
Contributor Author

Crap, i did not intend to push that button - i'm still new to github.
Btw, can i set a label for the issue myself or does the maintainer have to do that?

@jjg
Copy link

jjg commented Jan 7, 2013

Yeah I'm surprised that button doesn't have confirmation (although I guess it's reversible so...?).

I think only the repo owner can set the tags, at least that's how it appears (I can tag in my own repos but not this one).

@catohagen
Copy link

agreed, i cooked up some layouts in Paint, i think more tabs
test

if possible, to keep the funky graph, all the info text could be inside the graph?, wouldnt matter to the graph i think

test2

@Lenbok
Copy link

Lenbok commented Mar 16, 2013

A mobile friendly single-column layout would be a godsend!

There may be too many tabs for a wide tab-bar at the top like that, here are- a couple of alternatives: switch using a drop-down chooser; or just make the current tab title prominent and allow swiping left and right to switch between them; or have a separate tab chooser view and from within a tab either swipe left or have a "menu" button return you to the tab chooser page.

@foosel
Copy link
Member

foosel commented Mar 16, 2013

If I'm not entirely mistaken, @daprice is already working on something.

@daprice
Copy link

daprice commented Mar 16, 2013

Yep, working on using Bootstrap's responsive features to make it condense into a single column on smaller screens. https://github.com/daprice/OctoPrint/tree/responsive

Not totally sure what I'm going to do about the tabs yet. Currently they just wrap to the next line; they work, but don't look good. I may just switch them to Bootstrap's "pill" style when they don't fit on one line.

@daprice
Copy link

daprice commented Mar 25, 2013

Ok, I have my responsive layout branch at a usable state for the most part. I'm using it with my iPhone and it's a huge improvement over having to zoom in on the main layout. It might be good if people could also test on Android or other devices, although I'm not aware of anything that could cause problems there. @foosel, let me know if you think it's ready for a pull request.

Areas that could still be improved (of course, I would welcome any ideas or implementations):

  • the action controls on the gcode file listing are clunky on a touchscreen and (at least on iOS) currently take two taps: the first opens the popover and the second actually activates the control. This is partially due to some limitations of Bootstrap's popovers. Also, the action controls are rather small to use on a touchscreen; fixing both of these problems at once might require redesigning those controls.
  • the Gcode viewer currently does not scale to fit the screen; when you open the Gcode viewer tab you can still zoom/scroll to see the whole thing. This may require some changes to the gcode viewer to be able to dynamically handle the canvas element changing size. I didn't want to make potentially major changes to it right now because of GCode viewer options non-functional #35.
  • I haven't tested how the responsive layout affects the timelapse viewer since I don't have a webcam set up with octoprint, so the timelapse stuff may or may not look good on mobile.
  • the connection, state, and files accordion sections take up quite a bit of vertical space on the single-column mobile layout. It might be a good idea to minimize some of them by default on small screens and/or save their state to localStorage so they stay minimized across page loads.

@foosel
Copy link
Member

foosel commented Mar 30, 2013

Just chiming in to say that I haven't yet come around to taking a look at this due to this bloody flu I've managed to catch myself. While I'm at least able again to use a computer and do some minor stuff, it might still take a while until I'll manage to properly review your branch. Sorry for the hangup and thanks for your patience.

@Lenbok
Copy link

Lenbok commented Apr 4, 2013

I gave this a quick try and it looks very promising. Currently on the mobile it is essentially one tall single column - it'd be nice if there was a quick way to jump between the sections. Also, when viewing on a regular web browser, the spanner function in the "Files" section isn't working for me.

@nicolinux
Copy link

Another option would be for OctoPrint to expose a small API. As an iOS developer I'd rather build a native app instead of loading a condensed version of OctoPrint in a webview.
For a simple status app I would be happy to know about the printing progress, temperature and maybe have a few controlls in case something goes awry.

@foosel what do you think?

@foosel
Copy link
Member

foosel commented Jul 4, 2013

@nicolinux I've actually thought about exposing the API that is currently in use for the frontend. OctoPrint recently got an API Key setting and a couple of methods that already use this for authorizing access, I'm just still undecided on whether to establish a secondary API next to the one used for AJAX right now (that would have the advantage to allow me quicker extension/changes in case of new UI features, without having to take care of backwards compatibility) or just document the existing one and just enhance this with some additional resources that go beyond what the UI does right now (e.g. the currently available upload/select/load API), that would have the advantage of me eating my own dogfood ;) and not having to do everything twice.

Decisions, decisions, ...

@nicolinux
Copy link

Hm, tough choice. I'd favor the one API solution. On the up-side it will remind you to keep things simple and not add too many features :)

@MrBalonio
Copy link

I am currently working on a web app which does just this, is not an ios
app, but i been thinking about writing one if we have some interest.

Ill post the code soon

On Thursday, July 4, 2013, Sorin Stefan Nicolin wrote:

Another option would be for OctoPrint to expose a small API. As an iOS
developer I'd rather build a native app instead of loading a condensed
version of OctoPrint in a webview.
For a simple status app I would be happy to know about the printing
progress, temperature and maybe have a few controlls in case something goes
awry.

@foosel https://github.com/foosel what do you think?


Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-20483523
.

"Be like water making its way through cracks. Do not be assertive, but
adjust to the object, and you shall find a way around or through it. If
nothing within you stays rigid, outward things will disclose themselves.

Empty your mind, be formless. Shapeless, like water. If you put water into
a cup, it becomes the cup. You put water into a bottle and it becomes the
bottle. You put it in a teapot, it becomes the teapot. Now, water can flow
or it can crash. Be water, my friend."

  • Bruce Lee

@Scientist-LoveFossil
Copy link

Just leaving my two-cents, I love that I can start and view prints through my mobile browser. This absolutely rocks! A feature I would like to see, and I think this is more iOS than OctoPrint, is to select a gcode file from dropbox to upload. Currently, when this button is clicked on an iPhone browser, the only option is to upload from the camera roll.

@rooiejoris
Copy link

@daprice: I haven't seen your solution yet [UPDATE: i have checked it, i like the 'responsive'], but peter told me today about the responsive branche... I was also doing some layout tests/sketches which should be better for mobile devices. I think also that there is a difference between 'operating' and 'monitoring' the 3D printer. For operation Octoprint works good, i think for monitoring there is too much information you don't -really- need.
Since I use ultimakers, i am very used to the controller on the machine. I was involved with the very first prototypes of the controller and although the menu structure is not the best [it almost didn't change since my first sketches] it would be really nice to have more or less the same setup in the mobile version.

  • 'main' screen with main info: temp / speed?! / percentage[and or time left or something with time] / file name
  • when not printing: prepare with: preheat / cool down / home / move axis / disable steppers / ...
  • when printing: tune with: speed / temp / flow / fan speed
  • card menu / files
    and maybe some more options like webcam / connect / terminal et cetera more to the bottom

I did make some sketches once 5 months ago with the jquery mobiles stuff. For most things it would be nice to use sliders AND an input field. Unfortunately i cannot get the sliders [http://www.eyecon.ro/bootstrap-slider/] up and running [i am product designer, not a developer] otherwise i could have shared some thing already somehow. Furthermore i changed everything to accordion areas to show everything below each other.

In the title of the 'main' accordion changed the original title to 'filename' - 'temp' - '%' since that are maybe the most important things you want to know.

image

please let me know what you think...!

cheers\joris

@peteruithoven
Copy link
Contributor

I think someone needs to make a mockup of the whole interface, describing how interfaces should look hardly ever works out. Tip; if you you're not fluent in Photoshop, Illustrator etc, try Excel or even paper.

@CptanPanic
Copy link

Another problem I have running on mobile, is it uses lots of cpu and battery. I am not sure why but at least on firefox, it seems to keep updating in the background, and unless I close tab, kills my battery.

@adeebshihadeh
Copy link

I may start working on an iOS version. Would anybody be interested?

@nicolinux
Copy link

Hi,

I am interested but sadly I don't have that much time for it. But maybe I can help out.

@ssshake
Copy link

ssshake commented Oct 14, 2014

My 2 cents here, for mobile I don't need the full robust UI, I really want it mainly for checking status from phone remotely but more likely I want to use this as a diagnostics tool/remote control when working at the printer.

To explain. When I'm physically standing in front of the printer I want a way to easily move the print head around, extrude filament, home, calibrate and pause/cancel a print. So I really just need big simple buttons, on my touch screen device, kind of like a TV remote control

I can see from others comments we're on the same lines here, I'm considering just writing my own page with big dumb buttons and a small status window by use of API calls. However can I actually move the head, start/stop etc using API? AKA passthrough gcode via API.

@danfinlay
Copy link

I see there's a REST API for the print server now, and I was thinking it'd be a nice to have a minimal touch-screen interface for one of those 800x480 touch screens for Raspi going around (Like this one I just ordered). I doubt I'll do my slicing on the raspberry pi anyway, so all it's really doing is receiving files and printing them. All I really want is basic printer control, file selection, print starting, and an emergency stop.

Then I thought maybe this would look good with a Star Trek themed interface. Here's my first mockup of a UI.
octotft-concept-1

I already know I'll want to fit more UI in there. Maybe the busy style patch in the top mid could switch between views, or maybe selecting a file hides the file selector view to make space for extrusion and speed control.

@foosel foosel modified the milestone: Only as a plugin Mar 23, 2015
@seanreynoldscs
Copy link

Hey guys.
I'd like a safe area with just the data, graphs, image feeds, timelapse, etc all read only set apart from the high level end print, turn off lights, pause print, change filament, etc all normal commands set apart from advanced features like turn off fans, turn off motors, move build plate down or up, etc all commands which would break a print if things were going just fine.

That way I can open the app and not worry about my daughter coming over climbing up and accidently hitting the turn off motors button.

I can help I guess too. I can do the iOS app if there is an sdk example like others have mentioned.

Thoughts?

@adeebshihadeh
Copy link

@adeebshihadeh
Copy link

I've also just started work on a web app as an OctoPrint front end. https://github.com/quillford/OctoControl

@markwal
Copy link
Member

markwal commented Jan 23, 2016

If you've come here looking for a mobile web UI, you might want to try the TouchUI plugin from @BillyBlaze http://plugins.octoprint.org/plugins/touchui/

@danfinlay
Copy link

Awesome, nice work!

  • Dan

On Jan 23, 2016, at 10:54 AM, Mark Walker notifications@github.com wrote:

If you've come here looking for a mobile web UI, you might want to try the TouchUI plugin from @BillyBlaze http://plugins.octoprint.org/plugins/touchui/


Reply to this email directly or view it on GitHub.

@ssshake
Copy link

ssshake commented Jan 24, 2016

Ya thats pretty great. I'm excited to check it out.

@ssshake
Copy link

ssshake commented Jan 24, 2016

Also I would love an LCARS UI for this!!!. I have a spare 7" touch screen that I could connect to the pi and totally would if it was LCARS. Let me know if you proceed with this.

@danfinlay
Copy link

Oh I will. First I'll have to get my own touch screen..

  • Dan

On Jan 24, 2016, at 9:56 AM, Richard Bettridge notifications@github.com wrote:

Also I would love an LCARS UI for this!!!. I have a spare 7" touch screen that I could connect to the pi and totally would if it was LCARS. Let me know if you proceed with this.


Reply to this email directly or view it on GitHub.

@foosel
Copy link
Member

foosel commented Feb 6, 2016

With the TouchUI plugin there's definitely a solution for that now, so I'm closing this.

Big kudos to @BillyBlaze!

@foosel foosel closed this as completed Feb 6, 2016
@MoonshineSG
Copy link

MoonshineSG commented Jun 13, 2016

If anyone needs a different iOS optimised UI ... https://github.com/MoonshineSG/OctoPrint-Mobile

@foosel foosel removed this from the Plugins milestone Jun 20, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
request Feature request
Projects
None yet
Development

No branches or pull requests