Work area issues on iPad.. could it be bigger?

[dobkeratops]

Would it be possible to tweak how the image work area is calculated.. Sometimes it is actually smaller than in the browser view. Far too much screen space goes on padding. This is especially bad on the iPad which is a shame because annotating with the pen is amazingly fast.. but we can’t do it accurately with just 20%of its smaller screen (I think it’s the 4:3 aspect ratio.. on a desktop 19:10 display, there’s more horizontal space for that properties dialog)

Suggestions -

• make the too banner much smaller - even get rid of the bug “annotate all..” text - you’ve got the selector in the label list, and the overlay indicator in the bottom right (superior because it never scrolls out of view)
• Make the “properties” hideable, or move it to the left,under the the main label list (think of how photoshop deals with palettes).

Example of worst case tiny work area :

This shape image is paradoxically much bigger in the browser (opposite of what we want for browsing an overview then annotating precisely)

ideas for tweaked layout

[dobkeratops]

Going back to the ipad... what I’d tended to do is add labels on a pc (easier to type) but there’s now a neat handwriting text entry feature in iOS, which makes pure iPad use a bit better. (One caveat it keeps turning the entry into uppercase first labels.. I didn’t want to further pollute the data with those.. so I’ve stuck to alternating )

[bbernhard]

Yeah, that's the problem of those responsive design frameworks :/ But I think there are some options to change the layout depending on the device one is using. Do you use the properties on the ipad or should we maybe hide it completely from the user interface?

[dobkeratops]

Completely hiding properties if the window width is thinner than 1280 say would be a good compromise. I know those auto layout algorithms can do funny things in edge cases.

I’m also trying to figure out what pc window size is equivalent.. i had thought its like 1024x768 with high dot pitch (2048x1500) but it might be more like a 1280x800 window.. I’ll take some comparison screenshots using the top menu ..

[dobkeratops]

Right this appears to confirm: the iPad browser seems equivalent to a 1280x800 pixel window. Even this is tolerable for a PC user with a mouse and 21inch monitor.. it’s really the impact of trying to draw directly on it like a small page . So getting a direct impression without a physical iPad is hard

[dobkeratops]

Regarding iPad pen text entry support.. one possible piece of streamlining would be to turn the label to lowercase if it matches one in the official list (eg “Car”=“car”) but you might still want to enter capitals for product codes, acronyms, place names for free labels, so autoconverting all the time might backfire .

[bbernhard]

I just went down that rabbit hole and looked about an hour for a reliable way to detect whether a device is a mobile/tablet device. But with all those hybrid devices (desktop devices that have touch displays) and tablets with a really high screen resolution it's not reliably possible anymore to detect the device type. Oh man, I wish back those days where that information could be extracted from the user agent string...

What I've found is that media queries is probably the most reliable way right now to check whether a device is a mobile/tablet. So I guess I'll use some arbitrary screen width (like 1028px) as a threshold. Everything below that will be classified as mobile/tablet device and everything above that as desktop. That's certainly not perfect, but I guess it could work (maybe we need to tweak the threshold a bit in case it doesn't work for your device). I'll later do some alpha testing on my tablet and if everything works I think I could push it to production some time tomorrow.

[bbernhard]

Regarding iPad pen text entry support.. one possible piece of streamlining would be to turn the label to lowercase if it matches one in the official list (eg “Car”=“car”) but you might still want to enter capitals for product codes, acronyms, place names for free labels, so autoconverting all the time might backfire .

Looks like there are maybe some ways to turn that off. https://stackoverflow.com/questions/25786916/android-keyboard-defaults-to-capitalized-first-for-html-input

I'll have to check that later :)

[dobkeratops]

What I've found is that media queries is probably the most reliable way right now to check whether a device is a mobile/tablet. So I guess I'll use some arbitrary screen width (like 1028px)

right I think that will work, and it might even make sense on desktop PCs aswell. The specific size of the iPad does appear to logically be 1280 pixels wide by experiments above. (Evidently there’s some scaling, not just 2x pixels ie 1024 - 2048 as I originally thought)

regarding the text .. right I had looked for pen settings but there’s also keyboard settings. It also gives the lowercase version in a pop up.. that’s still better than using an onscreen keyboard. And I could always use a hardware keyboard with the iPad.

[bbernhard]

I just pushed a new version to production. It contains the following changes:

• the properties toolbox should be hidden for devices with a screen width <= 1280px
• I've added autocapitalize="none" to some input fields - so mobile/tablet devices shouldn't capitalize the first letter anymore. Not sure though, if I've caught all input fields. So if you stumble across one where it isn't working, please let me know.
• There's now a new query option image.num_annotations (e.g: image.num_annotations = 1). In theory it should also work with the < and > operators, but there are again some performance bottlenecks causing the browser to freeze - I really need to rework the database queries at some point to fix those issues.

[dobkeratops]

That’s great , I’ll try it out. Every one of those tweaks opens up some work or streamlines something

[dobkeratops]

Right, all helpful improvements. Num annotations=0 is as good as I’d hoped it would be .. plenty of varied images with labels already added (the gap in the “annotations vs labels” graphs) Non capitalised label entry using iPad handwriting means it’s much easier to work pure iPad+pen ... very relaxed experience Removing the properties view in thin windows has indeed allowed it to use the full width for the work area. The pc experience is undamaged

eventually I’m sure the iPad view could be tweaked with pop ups/expandable UI to show the properties aswell.. but right now I just use labels, so I don’t need it (I can just submit graph nodes to document free labels , to turn them into equivalent properties)