5 ms·

> The new mobile web version of Twitter is much faster and better looking than the desktop one. It's certainly much faster. I'm using it on my netbook which us

by chippy 10y ago

> The new mobile web version of Twitter is much faster and better looking than the desktop one. It's certainly much faster. I'm using it on my netbook which used to run the desktop version equally as fast. Why can't big development teams think about accessibility as it applies to older hardware? It's clear that it's getting to be a big problem for Twitter let alone other companies (see previous discussions about Bloat) The only thing I can think of is that the developers use the shiny new hardware and it runs okay for them. Or if the devs want to change, the management and board runs the fast hardware and it's "working for them".

RegEx 10y ago
Runtime speed has not been a priority in most apps/websites in a long time. Even relatively new phones struggle with things like modals and swipe effects on mobile websites. So much effort is spent on making things feel "native". Native, in my opinion, should mean fast before anything else.
- iLoch 10y ago
  Flipboard's mobile site is amazing at this. 60fps on mobile.
CaptSpify 10y ago
I mention this a lot but... I used to work at a place that had a ~5 year old pc on a <1Mb internet connection to test their software. If it ran find on that, then it would run fine on most of their users hardware. I wish more companies did this.
- CameronBanga 10y ago
  For the Android app development we do for clients, I have a $10 trac phone I got from Walmart.com. That was the phone price without subsidy or any extra cost. Android can be a bunch of hurdles, but we use same mentality as this for our app designs. I hear a lot of people in tech idolizing "good design". But is a design really good if it doesn't work everywhere? Performance should be a key factor of judging any design. Both heuristic user performance and actual measurable software speed.
ryanSrich 10y ago
There's no real way to measure hardware as it pertains to power and speed. The best thing we have is browser and OS detection. If there was a way to determine hardware that'd be pretty useful.
- paulirish 10y ago
  navigator.hardwareConcurrency provides the number of logical CPU cores. Additionally, GPU detection is possible with WebGL extensions. That said, this is clearly incomplete from what data would be ideal.
phamilton 10y ago
You're missing the point. The goal is to maximize a small set of metrics. Engagement, New User Experience, etc. They make these changes and roll them out. They look at the numbers. They see that 5% of their users (those on older hardware) spend 20% less time on the site. They see that 20% of their users are spending 50% more time on the site. They file a ticket about the drop in engagement for older devices. It goes into the backlog. Next sprint/quarter rolls around, they see a couple of options. One is to speed up the site on old devices another is to add a new feature that they estimate will increase engagement by another 20%. The second option seems to increase their bottom line more, so it gets funded and the old device support stays on the backlog. Repeat cycle. I can guarantee that at any sufficiently high traffic site they don't use developer hardware as a benchmark. They see the numbers, they know its slow for you and they make a conscious decision that you aren't worth the opportunity cost of new features.
- laumars 10y ago
  This but with one minor correction, the developers usually want to fix the experience. It's the management / project owners / etc that use the aforementioned analytics to make their judgement. Perversely, I've also often observed that those who spend the most time judging a sites performance on its analytics are usually the ones who actually use the site the least. or at least this is what I've observed with past projects I've worked on.
  - mistermann 10y ago
    One further (possible) correction: a "discussion" was had in the past whether to fix this, dev wanted to fix and PM didn't, or vice versa - whoever is the most politically powerful wins, regardless of metrics impact (all relevant facts aren't reported to senior management so sanity could prevail).
  - derefr 10y ago
    > those who spend the most time judging a sites performance on its analytics are usually the ones who actually use the site the least It's a weird part of human tribal/social dynamics. People who already generally like a thing are open-minded to new information that presents the thing in a positive light, and just generally ignore new information that presents the thing in a negative light. Likewise, people who already generally dislike a thing filter out the prosthelytizations of people who like the thing, but pay attention when they notice reasons to dislike the thing. Basically, our brains' belief-evaluation machinery is really just a wrapper around a core "generate excuses to keep thinking what I'm thinking" algorithm. We can exploit this—adversarial justice systems work much better than non-adversarial ones, because you've got two sides who each have paid attention to half the evidence, brought together in the same room to present it all. But if we aren't exploiting it, aren't even aware of it, it can become a real problem.
shivsta 10y ago
Check out this blogpost by Facebook on FB Lite (not vail in the US unfortunately, so I haven't had the chance to play around with it myself). https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-for-every-android-phone-and-network/ https://code.facebook.com/posts/1365439333482197/how-we-buil... As much as I dislike FB for other reasons, you gotta give them credit for caring a lot about performance.
darkclarity 10y ago
> The only thing I can think of is that the developers use the shiny new hardware and it runs okay for them. I think that was one of the problems with Google+ in the early days. They launched a social network that assumed a huge screen resolution (because that's what they used), so the interface was too big and clunky for a lot of people.
clemensley 10y ago
It's not only faster, I also think that the interface is actually much cleaner and focussed (only wish that the "new tweet" link would be sticky). Same is true for Wikipedia btw. Mobile version is much more readable imo https://en.m.wikipedia.org/wiki/User_experience https://en.m.wikipedia.org/wiki/User_experience https://en.wikipedia.org/wiki/User_experience https://en.wikipedia.org/wiki/User_experience

by chippy 10y ago

RegEx 10y ago

Runtime speed has not been a priority in most apps/websites in a long time. Even relatively new phones struggle with things like modals and swipe effects on mobile websites. So much effort is spent on making things feel "native". Native, in my opinion, should mean fast before anything else.

iLoch 10y ago
Flipboard's mobile site is amazing at this. 60fps on mobile.

CaptSpify 10y ago

I mention this a lot but... I used to work at a place that had a ~5 year old pc on a <1Mb internet connection to test their software. If it ran find on that, then it would run fine on most of their users hardware. I wish more companies did this.

CameronBanga 10y ago
For the Android app development we do for clients, I have a $10 trac phone I got from Walmart.com. That was the phone price without subsidy or any extra cost. Android can be a bunch of hurdles, but we use same mentality as this for our app designs. I hear a lot of people in tech idolizing "good design". But is a design really good if it doesn't work everywhere? Performance should be a key factor of judging any design. Both heuristic user performance and actual measurable software speed.

ryanSrich 10y ago

There's no real way to measure hardware as it pertains to power and speed. The best thing we have is browser and OS detection. If there was a way to determine hardware that'd be pretty useful.

paulirish 10y ago
navigator.hardwareConcurrency provides the number of logical CPU cores. Additionally, GPU detection is possible with WebGL extensions. That said, this is clearly incomplete from what data would be ideal.

phamilton 10y ago

You're missing the point. The goal is to maximize a small set of metrics. Engagement, New User Experience, etc. They make these changes and roll them out. They look at the numbers. They see that 5% of their users (those on older hardware) spend 20% less time on the site. They see that 20% of their users are spending 50% more time on the site. They file a ticket about the drop in engagement for older devices. It goes into the backlog. Next sprint/quarter rolls around, they see a couple of options. One is to speed up the site on old devices another is to add a new feature that they estimate will increase engagement by another 20%. The second option seems to increase their bottom line more, so it gets funded and the old device support stays on the backlog. Repeat cycle. I can guarantee that at any sufficiently high traffic site they don't use developer hardware as a benchmark. They see the numbers, they know its slow for you and they make a conscious decision that you aren't worth the opportunity cost of new features.

laumars 10y ago
This but with one minor correction, the developers usually want to fix the experience. It's the management / project owners / etc that use the aforementioned analytics to make their judgement. Perversely, I've also often observed that those who spend the most time judging a sites performance on its analytics are usually the ones who actually use the site the least. or at least this is what I've observed with past projects I've worked on.
- mistermann 10y ago
  One further (possible) correction: a "discussion" was had in the past whether to fix this, dev wanted to fix and PM didn't, or vice versa - whoever is the most politically powerful wins, regardless of metrics impact (all relevant facts aren't reported to senior management so sanity could prevail).
- derefr 10y ago
  > those who spend the most time judging a sites performance on its analytics are usually the ones who actually use the site the least It's a weird part of human tribal/social dynamics. People who already generally like a thing are open-minded to new information that presents the thing in a positive light, and just generally ignore new information that presents the thing in a negative light. Likewise, people who already generally dislike a thing filter out the prosthelytizations of people who like the thing, but pay attention when they notice reasons to dislike the thing. Basically, our brains' belief-evaluation machinery is really just a wrapper around a core "generate excuses to keep thinking what I'm thinking" algorithm. We can exploit this—adversarial justice systems work much better than non-adversarial ones, because you've got two sides who each have paid attention to half the evidence, brought together in the same room to present it all. But if we aren't exploiting it, aren't even aware of it, it can become a real problem.

shivsta 10y ago

Check out this blogpost by Facebook on FB Lite (not vail in the US unfortunately, so I haven't had the chance to play around with it myself). https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-for-every-android-phone-and-network/ https://code.facebook.com/posts/1365439333482197/how-we-buil... As much as I dislike FB for other reasons, you gotta give them credit for caring a lot about performance.

darkclarity 10y ago

> The only thing I can think of is that the developers use the shiny new hardware and it runs okay for them. I think that was one of the problems with Google+ in the early days. They launched a social network that assumed a huge screen resolution (because that's what they used), so the interface was too big and clunky for a lot of people.

clemensley 10y ago

It's not only faster, I also think that the interface is actually much cleaner and focussed (only wish that the "new tweet" link would be sticky). Same is true for Wikipedia btw. Mobile version is much more readable imo https://en.m.wikipedia.org/wiki/User_experience https://en.m.wikipedia.org/wiki/User_experience https://en.wikipedia.org/wiki/User_experience https://en.wikipedia.org/wiki/User_experience