Closed PaulKinlan closed 10 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.
Given this, the next decision is navigation. I see two options:
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)
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...
Http://weight.awrotwist.com has a nice slide out menu (I goes out too far IMO for this project but highlights the idea)
@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)?
This looks brilliant. Let's do this layout. (Sorry for the delay in replying currently on vacation this week)
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 ;)
Finally getting this moving.
After some experimentation, I decided to go with the following maximal width
breakpoints:
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).
Captures reduced window/device dimensions while still presenting a pleasant desktop version (largely through slightly reduced margins, widths).
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.
When setting width=device-width I am not sure nexus7 (2012) comes out as 800px.
But otherwise things genearlly seem reasonable. Look forward to seeing what is done. :)
@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.
@michaelsanford awesome, looking forward to seeing them.
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!
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.
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.
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.
Bigger buttons everywhere, here are a few more views. Again, an emulated Nexus 4.
@PaulKinlan How about we use the mobile menu trigger Maps Android is now using (maintain brand-consistent UI)? Something like this:
This is looking awesome.
@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 :)
@PaulKinlan I just checked out the merge and it looks like you did get everything relevant from my leafpile (with bbab7cf and 59ad9a4):
I just cloned Google's master and it seems to be working for me:
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.
I might have made a schoolboy error and not updated my local copy....
/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.
@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.
TODO we can split these out if needs be:
Currently the Sketchbot looks like this on a desktop:
However, on a mobile screen it is all cut-off
I am not quite sure how it should appear on mobile yet, so comments should include screen shots.