Elinks force refresh full#
Elinks force refresh software#

Two, I'll grant you that you sometimes have to use a custom control, because web moves forward faster than browsers, and so you can't count on a browser-level or OS-level calendar widget being available. It's true that users don't like change - and for good reason messing with UI invalidates their acquired experience, and even if you know you've changed only one small thing, they don't know that. You're conflating a couple of things here. If a large cohort of my customers tell me they don't want to improve their computer skills and want a fancy UI, who am I to tell them they're wrong? They're paying me. I recognize that the world doesn't revolve around me and my skills, interests and tastes. If it were up to me, I'd do everything in the terminal and never open a browser. I'm a vim-writing, tmux-ing, bash-loving developer. Yes, Chrome does offer a calendar for this field type, but Safari for desktop does not (just off the top of my head).

Elinks force refresh full#

They preferred the fancy datepicker because it let them see a full calendar and that enabled a more fluid conversation with the customer (like 'next Wednesday'). Within 24 hours we logged >1,000 tickets with users saying they disliked the change.

Elinks force refresh software#

They want the software to make things as absolutely 'user friendly' as possible.Īs an example, I tried standardizing on across our product (hundreds of fields). In my experience (years of talking IRL with thousands of users of my B2B SaaS product), there exists a large cohort of users that don't want to improve their computer skills. It's not evident to me at all that regular users 'want' to use these new web 2.0 apps, as much as they don't have a choice. However, it's users do not pay Google, and are forced to go with whatever Google wants to do, which is constantly hiding the older version and making it progressively worse to use. Google changes GMail, but its users still insist on using the older versions of the app, which is why they provide HTML mode, etc. The difference in these cases is that the users, by virtue of paying, actually have a say and so have required the companies to provide parity with the older and newer applications, and usage continues to not just be higher, but grow faster on the older versions (despite having a larger base). I've worked with 2 companies now where their users (and both these companies have users who pay 4 digit annual fees per user) have refused to migrate to the new Web 2.0 apps these companies have tried to foist on them. Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older 'apps' were running on computers which were orders of magnitude slower than our cell phones today. The average user, by Google's own studies, wants a faster experience. I look forward to seeing this bug resolved, and will be personally following up on the status of this bug.Īgain, I'm really sorry to see this, and I hope we'll be able to restore your ability to use Google with Lynx shortly! You can then use the key to iterate over the search results, and to select a particular result. In the meantime, as a temporary workaround, if you're open to using Chrome with a simple UI that would be amenable to a screenreader and keyboard navigation, you can use a User Agent switcher extension by Google to set the user agent header to Lynx and Google will serve the same HTML that it would have served to Lynx. Interestingly enough, pressing shows a list of links in the current document, and it does show all the available result links, so Lynx does see and parse them, it's just not rendering the links inline with the search results, so that's something we have to investigate as well. I filed a bug for our team to look further into it and address the root cause. Even though Google serves valid HTML to Lynx, it's probably HTML that Lynx cannot parse, and since it used to work before, this is a regression. I've reproduced the issue you described in the blog (Lynx does not allow clicking on the search results page). Thank you for posting this, and I'm really sorry and saddened to see this broken this is certainly not intended behavior. I am an engineer on Google Search frontend.