63 karma · joined January 11, 2017
Yes, obviously. And that hurts statistics. That's like killing sick cattle to be able to say that 100% of yours are healthy.
Another pet peeve is that they prevent screenshots simply because they can, and it feels safer. I know, 3rd-party apps which can do screenshots etc., but this is fighting the threat the wrong way. And yes, it's partially the fault of the platform, which could just allow user-initiated screenshots. Or at least make it configurable.
In case you're interested, the app is named "QuickÖV" - not relevant to anyone outside Switzerland, but just for trying it out: https://play.google.com/store/apps/details?id=com.billhillap...
On top of all that, you'd need a runtime that works on all platforms and is able to interact with native controls. I think React Native does something like that, but back then when I checked they did not have official web platform support (which is somewhat ironic, but I suspect technical difficulties too).
The problem with cross-platform frameworks is that they either focus on a good mobile experience, and web becomes an afterthought, or vice versa, meaning mobile basically embeds a browser. Flutter is one of former; back then the web variant was in alpha and basically just a canvas that couldn't even adjust aspect ratio. Since web had priority for our project (accessability, reactive scaling, etc.), this was a no-go.
We ended up going with Ionic (which is basically Cordova with some components on top). The web experience is tweakable to a low level, and the mobile experience is acceptably good, even if not perfect. And we get to cover 3 platforms with the effort of building for ~1.2 apps (there is some platform-specific work involved still).
I'm not even sure if cross-platform is at all solvable in a perfect way, since the UI patterns between mobile and web are just too different.
It was motivated by my girlfriend stating that it's hard to understand one's size in the various systems that are in parallel use, at least in parts of Europe. Worst part is that some systems have weird overlaps where not only they use the same "alphabet", but also the homonymous sizes partially cover the same range, but don't match exactly. Therefore it's impossible to exactly convert between sizes, and they should be derived from raw measurements.
I've been building a mobile app for quick and convenient public transport departure lookup in Switzerland[0], which is doable because there's a free, well-documented public API[1]. Since it's fairly popular, I thought about extending it to other countries, but as mentioned above, the API landscape looks super heterogenous and spotty.
[0]: http://billhillapps.com/billhill/quickov.html [1]: http://transport.opendata.ch/
DoodleDebug's output is HTML-based and interactive with semantic zoom. That means you can click parts of printed objects to inspect them.
However, I didn't work on it in years due to lack of time, and even the linked description page is a bit outdated (it's not an Eclipse plugin anymore).
[1]: http://scg.unibe.ch/wiki/projects/DoodleDebug [2]: https://github.com/CedricReichenbach/DoodleDebug
Edit: Maybe this PDF of my Bachelor's thesis gives a better overview of what DD is and does: http://scg.unibe.ch/archive/projects/Reic13a.pdf
Looking at the output directory, I saw that the fonts I'm using make up about 45% of the whole app!
What we ended up doing for now is a two-dimensional input layer with per-column one-hot encoding of characters (i.e. one character is one column, 128 rows for the ascii alphabet). Then, apply a convolution with kernel dimensions 3x128, which flattens data to one dimesion and combines three neighboring characters. The second part builds an "assiciation" between neighbors, which helps yielding similar outputs for similar word fragments.
This works quite well, except for some nasty limitations:
- Search queries have a hard limit in length, caused by our input layer dimensions
- Due to varying search query length, input nodes on the right side are often unused/zero, leading an weighting bias on the left side when training. That is, the start of search queries receives more attention that the end. But that's not necessarily a bad thing.
So if the NN has previously learned meaningful result priorities for "cargo", they should ideally also work out for "carg" (and vice versa) because of the live listing nature of our tool.
To our surprise, we couldn't find any example or description of someone doing this before. Is this such an uncommon problem or did we just not search in the right places?
FWIW, our use case is a search tool with live result listing, so we're dealing with word fragments and would like the outcome to be somewhat stable as the user types along. We ended up rolling our own, but it has certain shortcomings, such as a hard character limit.