[idea] mobile experiments about lab.js HOT 18 CLOSED

Here is a preview / rundown of an example github --> deploy --> container manifest!

Nice, that's really fancy! Love the binder integration — containerization FTW! 🙂

Excellent! You know what this means right?

Yes! 😁 I had thought about testing when I put together the component API, but I would not have dreamed that this would happen so soon — I'm really glad and excited that someone as awesome as you is working on this!

Please don't hesitate to let me know if I can support you — I'll probably be most useful on the lab.js side. I anticipate that this project will benefit from a few API additions that I've been meaning to make, but those will become much clearer once we work out how the testing happens, and see what is useful in practice.

from lab.js.

Hej Vanessa,

thanks for the question! Are you thinking about apps, or in-browser experiments on mobile? It seems to me that Flutter seems to be geared toward application development, did I catch that right?

With regard to browser support, lab.js is very much designed to work on modern mobile browsers, too; adaptations should be mainly cosmetic (iOS Safari and Chrome for Android work out of the box, though there are a number of legacy browsers around on old Android phones that wouldn't do a good job even if we backported all of the library logic). I don't have a smartphone to test things on regularly (Luddite here 😉), though I do borrow tablets when I can.

I guess there are a few low-hanging fruit that are worth a try specifically for phones:

• Reduce margins on small screen sizes
• Add mobile browsers to CI test suite / sauce labs run
• Get Felix a proper phone

Thanks for bringing this up, wanna help (with the first two)?

-Felix

from lab.js.

Hej Vanessa,

I've just gotten started on this, and have been working on point 1, which is probably the lowest-hanging fruit. Specifically, I've changed the styles so that the experiment 'box' doesn't insist on being wider than typical phone screens, and also the margins are removed on 'slim' portrait-mode screens.

Here's what it looks like:

Before	After

One thing I'm still worried about is font size. The above screenshots are from Firefox; In the Chrome Devtools preview, when I switch to a mobile phone view, the fonts are tiny (basically unreadable). I don't understand why this should happen, so I'm guessing that it might be a simulation bug. Do you have a moment and a smartphone handy for testing the font size? (I've put up the above demo at http://files.felixhenninger.com/2018/labjs-mobile-styles/). If you don't please don't worry, I'll pester my colleagues on Monday 😉

Thanks again for pushing this!

-Felix

from lab.js.

Ah, it looks like mobile phones require a viewport property. Checking that out now!

from lab.js.

Ok, looks like this is easily fixed. Wanna give it a try on a mobile device?

from lab.js.

I have an android, I'll test on it and send the screen shot in a second!

+1 on the viewport! I usually put something like:

<meta name="viewport" content="width=device-width, initial-scale=1">

And then sometimes for font sizes, if they are described in percentages (or other than pixels) you can get a good result. The other option if there are edge cases that aren't working for general, is to use media --> https://www.w3schools.com/cssref/css3_pr_mediaquery.asp.

from lab.js.

Awesome, thanks, updated the example!

from lab.js.

okay here are some tools to help you!

The one I like the best is just the browser itself - go to the Development tools, and in the upper left click on the mobile device button.

Your cursor will turn into a little circle, and you should be able to drag around and also resize the box to see what the result is. What I usually do is just do that with different sizes and look for weirdness :P

There are also a bunch of online services that do similar, "cross browser testing" eg:
https://www.browserling.com/

That's not a "best" recommendation, just a random one I found off of search. There are really nice ones that do a bunch of browsers at once, I just haven't tested fully.

And here are on my android - from gmail it looks okay but I can't see the bottom:

in the browser is the same (so if I didn't know, I wouldn't see the gray bar that is hidden and would be confused maybe):

and then when I scroll.. ahah! There it is! :_)

from lab.js.

Wow, thanks for testing this (and thanks also for the devtools pointer!). This took me down quite a rabbit hole -- turns out that the viewport height (which the styles use to determine the page layout) is calculated as if the navigation bars weren't visible, so that things don't go weird when you scroll and they move out of the frame (long-winded discussion I, II).

It doesn't look like this is something that can be worked around in CSS, it's likely that the study needs to adapt to this in the study code 🙁. Or do you know a way around this?

from lab.js.

Hmm, the chromium bug on this lists it as fixed. Gonna find out how -- gripping read! 😉

Some time later: Gonna postpone this specific issue for now -- this is going to need a actual device to test on. I'll pester my colleagues on Monday!

from lab.js.

Did you try using em values? I think they mean relative to a context, here are all the different kinds --> https://www.w3schools.com/cssref/css_units.asp

Yeah I need to run out too! Ping me when you need more testing (or no worries if not). I think as long as (something) is okay working on Mobile, I'm good to close the issue. I was actually thinking more along the lines of providing template items for something like flutter (so a labjs experiment --> a tiny mobile app) but it might be overkill.

from lab.js.

Did you try using em values?

Yes, already do! In fact, while overhauling the styles today, and switched to rem, which are apparently the latest and greatest in CSS size definitions.

I was actually thinking more along the lines of providing template items for something like flutter (so a labjs experiment --> a tiny mobile app)

Can we put that on our list of things we should definitely discuss, but maybe not in a GitHub issue thread? 😉 I'm really looking forward to chatting with you in New Orleans at the latest!

I think as long as (something) is okay working on Mobile, I'm good to close the issue.

Ok, so here's how things stand (polishing and then pushing commits now):

• The styles are updated, and should be in a much better shape
• I'm going to borrow some phones on Monday to try workarounds for the navigation bar issue.
• CI testing now also runs on Android (v6 and v7) and iOS (v10 and v11) emulators. I've chosen not to cover older devices, but I'm willing to support these OSes going forward, which I think is a fair trade-off.
• I think that for now at least, experiment authors will need to test things themselves (not only because the library could fail on older devices, but also because the device ergonomics don't always match the desktop model, as we discovered above).

Thanks again for pushing this -- I'll update the issue after looking at the styles once more on Monday, do you think it can be closed then?

from lab.js.

Yes definitely! Close when you are happy with mobile testing, and thanks for the speedy discussion! The experiment container deployment setup I'm working on is going to make it pretty easy to have automated testing for an experiment, and I made huge progress today in getting the final step (deploy back to GitHub pages) but still have been kind of slow because I'm still traveling.

Does LabJS carry around a data structure that has acceptable responses? Jspsych does, so I was able to create an automated testing robot. We should do similar for labjs!

from lab.js.

The experiment container deployment setup I'm working on is going to make it pretty easy to have automated testing for an experiment, and I made huge progress today in getting the final step (deploy back to GitHub pages) but still have been kind of slow because I'm still traveling.

That sounds incredible. I can't wait to see it in action!

Does LabJS carry around a data structure that has acceptable responses?

Yes! Every component in the experiment has a responses option that maps browser events onto qualitative responses. You can pass any response to the respond method to fuzz your way through the experiment without simulating browser events, or you could trigger the event once the component is shown.

I hope that makes sense -- please ping me on any channel (you'll find me on Slack, or I'll come on the expfactory gitter if you'd find that helpful), I'd be thrilled to help you with this.

Safe travels!

from lab.js.

Here is a preview / rundown of an example github --> deploy --> container manifest! It's sort of not put together yet, but the links can give you a sense of the content (minus the pretty page I still haven't made yet :P)

binder-examples/continuous-build#15 (comment)

Yes! Every component in the experiment has a responses option that maps browser events onto qualitative responses. You can pass any response to the respond method to fuzz your way through the experiment without simulating browser events, or you could trigger the event once the component is shown.

Excellent! You know what this means right? We can have this same build setup with an added step to run a robot --> https://expfactory.github.io/expfactory/integration-robots that will only pass the experiment tests given that the robot is happy :) I'm still struggling with yaml, so I suspect it will be a few weeks before I put this all together proper.

from lab.js.

Ok, so I've been testing this, and nagging all my colleagues for their phones over the past days 🙂. My take-aways have been this:

• The users I talked to all weren't worried about the navigation bar at the top on Andoid -- several said that they habitually scroll downward to hide the bar and have more space for the page content, and I think that's a habit that it would make sense to encourage for participants on mobile devices because the navigation bar will get in the way of the study otherwise.
• The width was still to large for some phones (in particular the iPhone 5), so I reduced it to 320px on tiny screens.

I think I've picked all of the lower-hanging fruit for the moment, so I'm going to close this issue for now. There's a lot still to do to make genuine mobile experiments work on smartphones in particular, and I have a long todo-list with outstanding things, but I think those won't fit in a single issue. If you're interested, I'd be happy to talk about specifics, and break things down if you'd like to take a shot at them.

Thanks again for initiating this, it's been great to think about this, and take some first steps in this direction!

from lab.js.

Very thorough! Apologies for delay, just landed from a flight. Everything looks good and thanks again for the speedy discussion :)

from lab.js.

Oh, no worries! This is super-important to me, I just don't have the bandwidth right now to polish all the aspects of mobile experimentation, so I'll focus on improvements on the desktop which will also benefit the mobile side, and make very sure that there are no regressions. As with everything, the first interested users will be the ones to really drive things forward.

from lab.js.