googlearchive / ChromeWebLab

The Chrome Web Lab for Makers, Hackers and everyone
Apache License 2.0
876 stars 278 forks source link

Make SketchBots mobile friendly #51

Closed PaulKinlan closed 10 years ago

PaulKinlan commented 11 years ago

TODO we can split these out if needs be:

Currently the Sketchbot looks like this on a desktop:

screen shot 2013-08-13 at 6 42 47 pm

However, on a mobile screen it is all cut-off

screen shot 2013-08-13 at 6 45 33 pm

I am not quite sure how it should appear on mobile yet, so comments should include screen shots.

michaelsanford commented 11 years ago

This narrow three-column interface seems already well-suited to a small portrait viewport: break the above three columns into self-contained, (nearly) full-viewport panels.

sketchbot mobile proposal 1

Given this, the next decision is navigation. I see two options:

PaulKinlan commented 11 years ago

Looks really nice!

One thing I am worried about is that a user would lose track of where the images have gone in a tabbed view... I suppose it could be indicated with a visual flash or status number update.

What about a vertical accordion stack? Or a slide out menu tray with the sections in (then it might be quite close to your diagrams then)

PaulKinlan commented 11 years ago

I meant to add that the reason why auto advance might not work is that there could be a queue of images being taken and being processed at the same time...

PaulKinlan commented 11 years ago

Http://weight.awrotwist.com has a nice slide out menu (I goes out too far IMO for this project but highlights the idea)

michaelsanford commented 11 years ago

@PaulKinlan Indeed, not being able to queue multiple pictures was a caveat of auto-advancing. Just throwing it out there…

Aerotwist's slide-out is kind of nice. So, you envision something like this (smaller, menu selection closes tray)?

moq_2 2

PaulKinlan commented 11 years ago

This looks brilliant. Let's do this layout. (Sorry for the delay in replying currently on vacation this week)

michaelsanford commented 11 years ago

Thanks @PaulKinlan. You can assign that to me (if you're using that workflow) and I'll get right on it.

Don't worry about response times: I'm not on vacation but thus have the same problem ;)

michaelsanford commented 11 years ago

Finally getting this moving.

After some experimentation, I decided to go with the following maximal width breakpoints:

> 960

Existing, since that's the existing fixed width of the desktop interface before horizontal scrolling (with existing margins). This also captures most tablets in landscape orientation, which will scroll vertically (which should be fine).

801px — 960px

Captures reduced window/device dimensions while still presenting a pleasant desktop version (largely through slightly reduced margins, widths).

800px

Nexus 7 (for example) is 800px wide in portrait mode. I figure on that and smaller we want the above mobile interface.

I'll post some screenshots when I get the last bit done. I don't mind waiting for that point for comments, unless someone sees a big problem already). Ref: My fork feature branch.

PaulKinlan commented 11 years ago

When setting width=device-width I am not sure nexus7 (2012) comes out as 800px.

PaulKinlan commented 11 years ago

But otherwise things genearlly seem reasonable. Look forward to seeing what is done. :)

michaelsanford commented 11 years ago

@PaulKinlan You might be right, I haven't done too much testing yet (just going by the spec, and using it as a rough estimate for what we might look for in terms of interface transitions).

I'll post some screenshots when I have some more to show.

PaulKinlan commented 11 years ago

@michaelsanford awesome, looking forward to seeing them.

michaelsanford commented 11 years ago

Here's a simulated Nexus 4 (tested in Canary 31.0.1622.0). I have to work out a few small quirks, lint and performance profile, but here's something to look at, at least.

I wonder that the horizontal pipes are not obviously a menu disclosure trigger (particularly in this orientation). the trigger hides when in desktop mode. What do we think about increasing the button size ( New From…, View… )?

Bring out 'yer comments!

waiting

menu

completed

waiting landscape

Worth reminding: currently, Safari iOS and Chrome vanilla don't support WebGL (which causes Three.js to fail to create a context in which to do anything). So, this app is likely (currently) limited to Opera Mini, FireFox, and Chrome Android via flags.

PaulKinlan commented 11 years ago

Awesome work.

re:three. I believe this was only ever used for the background image, to make it curve.

re:screenshots. These are look great! I would change the menu icon to be the burger menu icon people are using nowadays, and have it positioned further up on the top left. We will probably have to sort out the logo and get it moved..... I would be open to making the logo the "toggle", but I am not sure how discoverable that is.

The "new from *" buttons, we should make them full width and bump up the font size. I would also make each of the white photo holders full width too.

michaelsanford commented 11 years ago

Thanks for the feedback @PaulKinlan ; I'll integrate it!

I'll also have a look at mitigating Three.js's killing Safari iOS, if it's not really necessary.

michaelsanford commented 11 years ago

Design

Bigger buttons everywhere, here are a few more views. Again, an emulated Nexus 4.

Webcam (Portrait)

portrait capture

Webcam (Landscape)

landscape capture

Using a file

portrait file

In progress

portrait in progress

Completed

completed

Better menu trigger?

@PaulKinlan How about we use the mobile menu trigger Maps Android is now using (maintain brand-consistent UI)? Something like this: New Mobile Menu trigger

PaulKinlan commented 10 years ago

This is looking awesome.

PaulKinlan commented 10 years ago

@michaelsanford the thing I just merged, was I supposed to merge it? I am looking at the code and I don't see anything mobile :)

michaelsanford commented 10 years ago

@PaulKinlan I just checked out the merge and it looks like you did get everything relevant from my leafpile (with bbab7cf and 59ad9a4):

  1. ChromeWebLab/Sketchbots/sw/ui/view/RobotsView.css Mods start here
  2. ChromeWebLab/Sketchbots/sw/ui/controller/RobotsMainController.js Mods start here
  3. ChromeWebLab/Sketchbots/sw/ui/view/RobotsViewStrings.js Added navigation header
  4. ChromeWebLab/Sketchbots/sw/ui/controller/RobotsTopicQueuesController.js Added some properties

I just cloned Google's master and it seems to be working for me: screen shot 2013-09-18 at 9 36 23 am

I'd note that the width breakpoint for the stuff pictured above is 615px, so most tablets in landscape (many in portrait, too) will get the desktop-looking one with narrower margins. Easily improved, I was just eager to push something upstream so you can finally play with it.

PaulKinlan commented 10 years ago

I might have made a schoolboy error and not updated my local copy....

PaulKinlan commented 10 years ago

/me hangs head in shame.

@michaelsanford thanks for all this work by the way! I am going to start promoting it more!!

I will start making separate issues for things that I find now and you (if you want), me, or anyone in the community can pick them up.

For instance, I can't see a viewport meta element - we need this.

michaelsanford commented 10 years ago

@PaulKinlan It was a lot of fun and I'm definitely still interested in continuing my involvement.

Woops, I did neglect the viewport! I'll add it.

As a side-note, one of my primary volunteer projects is running a robotics competition for high-school students. I'm pushing to deploy one of these at the competition this year, just for fun.