> the article is very low quality. Here's a link to the actual paper
I appreciate the link to the paper. But I consider the article superior in a few ways:
(1) It is brief, and targeted to an audience that is not a specialist in this field.
(2) It includes the video clips (which, to be honest, speak for themselves) and does not require any special credentials or university affiliation in order to view.
> That title is unconscionable
Yeah... the title is rather stupid. It should have gone with just "This Is How Tardigrades Walk".
It means that when they saw the video it provoked an unexpected emotional response.
As others have said, it's not a good title, but I'm treating this as a sincere question because I know there are many non-native speakers that could get confused by this stuff.
Unconscionable is surely a step too far? Translating "Tardigrades exhibit robust interlimb coordination across walking speeds and terrains" into the title of the article seems like a reasonable thing for a pop-sci publication to do. Appreciate the link to the actual article!
Latency is the biggest problem with video meetings and I can only imagine it's worse with this.
In normal human interaction you can see people's reactions to what you're saying and doing within microseconds of taking an action, you can subtly and automatically adjust your presentation, your pace and your expressions to build greater rapport. Over video calls you need to introduce artificial pauses to make sure that everyone has caught up, and it's really jarring compared to being face to face.
The latency on this should actually be better than video calls.
Since all the character assets are downloaded locally, the only visual data that needs to be sent across network is the positioning of facial features and hand movements - which is a much smaller payload than streaming video. More akin to the latency you'd see playing Call of Duty or something.
I could see this experience being higher fidelity than video calls, especially in poor network conditions.
This is only true under the assumption that you can analyse the video and extract the movement/features as quickly as you can stream video to the network. Given how optimised streaming of live video is and how hard video analysis can be, it's not at all a given.
I'm not sure I follow? When you use Workrooms you're not streaming video.
The application is taking the positional data of your headset/controllers and translating that into how your avatar moves around. There isn't any video analysis going on.
You said "the only visual data that needs to be sent across network is the positioning of facial features and hand movements". To extract facial features and hand movements is non-trivial and requires video analysis and may hence involve lag.
In a previous role we did some light research into this, you tend to notice latency in movement at around 40-80ms, but thats from your own movement vs avatar.
However, you don't notice it in other people's movements until there is a mismatch between social clues, Even then you have up to 250 ms (sometimes more, depending on the pace of the conversation)
In practice that means you can do an atlantic call without really noticing it.
the problem with VC calls is that because video needs to be matched to audio, the audio is buffered to make sure its lined up, this means that you have a 250ms+ delay plus any time to switch presenters.
I agree with this. There's work done by NVidia on AI Video Compression around facial ticks and reducing latency and bandwidth. Maybe these two approaches can be combined for a best-of-both worlds result.
This is quite subjective. My opinion is not very representative, but I for one find teslas horrifically bulky and ugly (and most other cars, in fact). They all look like gigantic broken eggshells. On the other hand, a lidar rig looks very cool.
I still really prefer a hardware keyboard and miss my android G1 in many ways. I'm typing this on my touch screen phone and it's so much slower than texting was even on an ordinary numeric keypad with predictive text. For me touch screens ended productivity on phones and they solely became consumption devices
I'm surprised nobody has implement something like the numpad + predictive text on a touch screen. It would make a lot of sense having less buttons to mis touch.
There are Android keyboards that replicate it. I tried a few but for whatever reason they still couldn't replicate the experience. I suspect it's the lack of hard buttons - I could type out an entire message without looking at the screen with a T9 keypad.
I've ended up switching to a swipe keyboard which I find efficient but it in an entirely different way to T9.
For some inexplicable reason new Nokias seem to have ditched T9. The one feature that gives 'dumb' phones an edge over touchscreens has been abandoned. The replacement is a horrid, crappy and eminently useless home - grown editor that is worse in every way. It seems Nokia execs enjoy shooting themselves in the foot. But anyway, their phones are irrelevant, it's just a pity that they seem to be going backwards.
The Microsoft-Nokia didn't want to maintain the old OSs so went with a licensed clone of Series 30, and then post-Microsoft went with KaiOS (though newer ones seem to be back on the Series 30 clone, which is frankly a better experience than KaiOS was). Like, I was never a big fan of Series 30 or 40 but they had an awful lot of iterative improvement over the years and they just pissed that all away.
KaiOS (if that's what it's called) is crap and almost unusable. The Symbian series and more basic OSs were pretty complete and nice to use. Nokia no longer make good phones, or even mediocre phones.
> Such T9 formats for text entry therefore remain available in all latest [as of August 2020] iterations of LG keyboards, certain Samsung keyboards, and third party T9 keyboards such as Go keyboard for Androids and Type Nine for iPhones, as shown on this LG V60.
Also, there was another method of touch input that used swipe gestures to write words, I can't remember the name, but I remember that it was far from intuitive to use.
No I loved those buttons, and find miss-touching a screen so much easier! I could bash out messages on my Nokia 8250 without looking at all, and could type away with the phone in my bag. I'd love to know what my typing speed was actually like back then, but it sure felt fast!
You're underestimating the level of breakage here, it's not just a few tutorial sites it's tens of millions of websites, many unmaintained. Like them or not alert(), confirm() and prompt() are key pieces of functionality depended on for literally decades now. I'm trying to imagine the economic cost of this change and it's just enormous.
I understand that. But that was the case with popups as well. Remember when we needed popup blockers? Straight up removing the functionality is of course a drastic measure, so realistically I could see something like what we did with popups, where the browser first asks you if you'd like to allow alerts on the page, and only allow them to be shown if the user explicitly chooses so.
Do you have any idea how much of the web will break if alert(), confirm() and prompt() are removed? Tens of millions of websites, many of which are no longer maintained will stop working. This is the destruction of the web over a UX issue - fix the UX issue, don't break the web!
Those functions should be deprecated and new applications should be discouraged from using them, but they should never be removed.
> Yeah, I think the most likely eventual "removal" path is actually non-blocking alert(). (confirm() and prompt() cannot be converted to non-blocking though, so they'd have to be fully removed)
Blocking Javascript execution is a fundamental part of the `alert` spec. Replacing it with a different, non-JS-blocking thing that happens to share the same name doesn't mean that `alert` wouldn't be removed as it exists today.
And there's just no way at all to make `prompt`/`confirm` non-blocking, they have to block the main JS thread in order to keep the same API.
That breaks the web by definition. There is no way to implement a non-blocking alert(), confirm(), or prompt() in a way that doesn't break existing code that uses them, and that's a lot of code, a lot of the web.
the alert(), confirm(), and prompt() themselves interrupt normal browsing, so I'm not sure what you mean here. They're synchronous so block the main thread, but they also block other user interactions until they're dismissed, so what would be the benefit in leaving normal browsing unaffected if the user cannot browse anyway?
it's not good, this change will break huge swathes of the web if it goes ahead as planned, lots of older websites just won't work any more and many newer ones will also be affected.
There is no place for an out of dom signalling mechanism like alert() on the modern web. I would hope to see a multi-year phase out of something this integral. I can't remember the last time I saw it used for something useful.
deprecation is totally fine, log a warning in the console, discourage people from using it, but don't throw the existing web under a bus because your UX team can't think of a nice way to visually distinguish it from the browser's chrome!
> can't think of a nice way to visually distinguish it from the browser's chrome
i don't think it's about visual design. Having a signalling mechanism that lives outside of the dom is confusing to users, and alert is a rare exception from wayyyy back when. It looks like google is doing this for user security, and I support it.
I don't support the way they're going about it. If Mozilla and Microsoft and W3C are willing to get on board, I would greatly support it. But this is more throwing their weight around, and it sucks!
>existing web
i'm gonna be honest, i havent seen a meaningful alert be used in recent memory, and i work with a lot of web apps. All alert()s could be easily replaced with something inline. I'm not a huge fan of breaking changes, but this is one (with a multi year rollout) that I would support.
It isn't uncommon for me to find a site that uses it legitimately. Sometimes for telling the user info, sometimes for reporting an error, and sometimes for other goals.
Sure, it'd be better if they did it in a more normal manner (writing their message into an HTML paragraph), but they do use it.
But a lot of these sites are dead (though some aren't) and so it for the most part doesn't matter if you remove it now or after three years. They'll still break or lose functionality.
Just spit out a warning to the dev console when it is used.
> In general all of the simple dialogs (alert(), prompt(), confirm(), and beforeunload) are deprecated and being removed slowly but surely from the web platform. They use trusted browser UI, which opens them up to abuse, and they block the event loop, which is not in keeping with the web's cooperative task model. So this is just a first step toward eventually completely removing them, which will take many years.
The UX issue is directly highlighted in their rationale for the change.
Calls to alert(), confirm() and prompt() cannot be polyfilled or safely replaced in the general case because they explicitly block the main thread. That behaviour might not be desirable, but it was the path chosen when the relevant code was written. While some maintained applications will be able to switch to asynchronous alternatives, many older and unmaintained websites - the long tail of the web, will stop working.
Pretty sure it's a different problem - alert() is a true modal dialog that blocks almost all other normal interactions and is very disruptive. Back in the day when apps weren't constantly gaming all user interactions to squeeze on extra ad click out or whatever, it was still abused - but rarely.
Now if you wander down the wrong internet 'alley' you'll get mugged by someone using alert() to almost completely hijack your normal session. Especially for older folks (my grandpa really suffered from this), it becomes impossible - to the point they'll even call someone up and give them their credit card number sometimes so they can 'get to their email'.
Warnings to the dev console won't stop this type of harassment of users - only stopping it from being the modal dialog it is supposed to be (per alert() prior behavior) will.
edit: title was edited