That number seemed surprising to me - I actually expected the portion of mobile-only internet users would be significantly higher than that.
Turns out the 15% number means something slightly different. From that Pew Research page:
"Today, 15% of U.S. adults are “smartphone-only” internet users – meaning they own a smartphone but say they do not subscribe to a home broadband service."
So the 15% is people who use the internet exclusively via LTE/5G without paying for home broadband.
I would guess that the number is pulled down significantly by streaming services and a lot of home broadband connections are 95% TV service, and wifi connections for phones at home is just a bonus.
No kidding! This is my first time experimenting with converting Keynote slides into HTML, so I'm not surprised it didn't go perfectly. I just pushed a quick fix for the overflow issue but should probably figure out a longer-term solution.
>That number seemed surprising to me - I actually expected the portion of mobile-only internet users would be significantly higher than that.
Gen Z is likely higher. Older generations will still use a laptop.
In lower income countries, this number is also higher. Many people do their entire job on their phone. Email is not used often for business. It's chat apps.
I am curious to understand what bearing "lots and lots of regular people solely use their cellphone to conduct consumer transactions" has on GitHub, whose audience is significantly different than median and cannot otherwise function without a laptop/desktop.
I don't know but I really wish it was possible to have the web desktop in mobile, GitHub has a terrible app that can't do anything and even worse mobile view. In the past it was possible to tell it to run the desktop version of the website with the browser setting but this isn't possible anymore. I have a very big phone, it's screen has a ton of pixels, just give me a grown up UI exactly like the desktop instead of the dumbed down, way too zoomed in whatever thing you are offering on mobile.
If it works for you then great, I guess. But that sounds like the equivalent of using nail clippers to mow the lawn. You're forgoing a good tool for an absolutely terrible tool.
What exactly is your use case for doing edits on your phone? Are you making these edits while out and about without your laptop (in line?) or do you actually avoid getting your laptop out even when it's close by?
I've been blown away by amazon/gcp/azure whose uis progressively waste more and more space. I actually measured it, and on a normal (11"?) laptop screen the list of vms occupied something like 15% of the screen space, the rest being sticky pannels, banners, sidebars, toolbars, etc. Combined with "resizable" panes that are restricted to max 30% of the parent area size I can see between 1 and 2 lines of results. Not desktop/laptop, they don't even work on laptop.
I reported it in those offline "please rate the new ui" feedback popups, but it's clear that they have no idea who use their UIs.
I long for the late 2000s/early 2010s style of web administration UIs which tried to sorta-kinda look like a desktop app, they'd have things in like, tables trying to be like LVS_REPORT where you'd rarely have to scroll and rows were 14 pixels high etc.
Nowadays stuff like this is a sea of divs with an ocean of margins and padding. Or just straight up card-based layouts.
This presentation was more about industry trends than GitHub specifically. My point here is that as time in apps becomes a greater portion of the average user's time on the internet, the more poorly-built web experiences will stick out.
If the “mobile” app had feature parity, maybe we would not be so different from the median? Github has cloud development tools; why can’t I use them with the keyboard and mouse connected to my phone?
I imagine because practically 0% of the population have mice and keyboards attached to their phone. You can go to vscode.dev and similar on a phone web browser if you really wish.
Using availability as a metric for UI bugs is great. After all, UI is just an API for humans, and it breaking breaks workflows.
> These unique kinds of UIs have less convention and unique accessibility characteristics that are expensive to solve. But a lot of the time, our budget should be zero. To build it with what we have already. To copy-paste.
If you build UIs like this, you end up with the sort of one-size-fits-all UIs no one likes. Like when Twitter (and others) consolidated their desktop and mobile UIs into one mobile-first one that works worse on. You waste a bunch of space and information density, lose eye scanning ability, for the benefit of higher developer velocity. It must be carefully applied. Things like shipping address forms (example from article) or yes/no modals are a great place for standardization but trying to assemble those pieces on a single page, or show something slightly different and you're back to square one.
---
Didn't we try to standardize some of this already? Isnt this why <input>s are derived from the OS and why alert() and prompt() exist? And default style sheets? And no one wanted this! Browsers have opened up _everything_ to be customized, capitulating to designers. And even with all that customization, some things like HTML5 validation still feel like theyre missing pieces.
Github is the worst of the web GUIs I use regularly. Started bad and only got worse, luckily 99% of my gitting is via PC based tools. Maybe this is the kind of app where the GUI should be modeled on client side developer tools and not modern web UIs.
Historically I've thought the GitHub web UI was great - clean, usable, simple. Over the past couple of years it's started to get more and more feature bloat, to the point where it's becoming less usable.
Thinking back on it I've used Github nearly since the early 10s. Today I find myself wondering how the fuck I get a list of all issues for a project. For fifteen odd years I've been able to clear the search box of the "is:open" and "is:whateverfuckingelse" bits and just get a list.
Now? Whatever UI update they've just pushed isn't reflected in the documentation. I can't think of anything that's been improved since GH decided to reinvent text rendering (and poorly at that) and then double down on it.
Upon further inspection it sort of works if I log in. It behaves differently at least. Ugh.
I've only used Github desktop briefly so I can't say much about it, was commenting on the web UI. I suppose if I was using a lot of GitHub functionality vs. just using github.com as a repo things might be different and I'd give Github desktop another try.
Sorry, that's what I meant actually, the web UI. I said desktop to differentiate it from the mobile web UI, but I realize that was the wrong way to say it because they also have a desktop app.
Ugh. GitHub's UX has been getting so much worse over time. :( :( :(
They even completely break super basic things that used to work fine.
For example, if you want the direct download url of (say) an image file in your repo you used to be able to hover over the "Download raw file" button and the status bar would show you the url.
But no, no any more. It's now some kind of javascript button bullshit and there's no way to get it to show the actual download url. Clicking it at least downloads the file, but the history entry is messed up "blob:..." and also doesn't show the download url (using Firefox).
Because at GitHub they clearly can't leave alone the things that actually work, and need to change things just for the sake of change. Seriously not impressed. :( :( :(
Stats about general internet usage should mean very little to GitHub since it is used by a specific subset of the population which I'd wager is way more heavily skewed towards laptop/desktop
Also shouldn't they be able to just know this based on traffic? Why the need to use third-party general research as a source rather than "Our traffic patterns suggest X"?
Yeah. Looking at stats without context of their audience is what caused the Xbox One disaster. They saw a huge number of hours on Xbox 360 being used for watching streaming shows, so they thought that was all anybody cared about, ignoring the fact that their audience still bought the device as a game console and that alot of those hours were relatives and housemates.
The one was a crap console all around, but Microsoft’s auth BS is what finally got both of them stuck in our attic. More recently, this happened with minecraft.
GitHub recently forced me to turn on 2FA over SMS. Now they’re running a banner telling me that it has all the problems that were the reasons I didn’t want to turn it on, and telling me to turn on some other 2FA instead.
Glad to see some discouragement of custom design systems. I shudder at the person-hours that have been squandered on that fruitless endeavor. Pre-web, essentially zero time was spent on "design systems", and we were all better for it.
Absolutely. The work of user experience research has a long history and is very important. What is new is every single "app" (website) inventing their own entire conventions and "language". This still happened with desktop apps, but it was rare typically limited to the largest players (Microsoft, Adobe). You can do a tremendous amount with basic, bog-standard, GUI widgets if you apply them well.
Part of the problem is that we just don’t have a std lib, or std UI framework for the web. In both Windows and Mac, the basic UI happy path involves using the pre-built libraries and UI components these companies created to make apps somewhat consistent. There is nothing like that for the web — which is part of what the article gets at.
Quite a few of them, yeah. jQuery UI was a huge, massively widespread thing for a while too.
People still do their own things of course. Like how tons of Windows apps build completely custom stuff (e.g. Winamp). Or very nearly every single videogame.
I guess people have different experiences as I don’t see the React changes as improving the mobile experience: just the opposite. I often interact with GitHub by browsing through the file tree and various links. But the new react renderer breaks the back button. So often when I’m browsing and hit back, I leave GitHub entirely instead of going back to the parent directory.
Between the back button issues and the horrible sluggishness on many repo and pull request pages, the React switchover has seriously degraded what used to be a great experience. Not just on mobile, but on desktop as well.
I believe this is misinterpreting the app usage trends. While the number of minutes on mobile is heavily skewed to apps (ex. 90%) the time is also spent in a very small number of apps (ex. Instagram or YouTube). It's not clear how that trend applies to something like GitHub or developer tooling in general.
I would like to see renewed focus on supporting the user to be able to customize the UI to their liking. This is sorely missed in design systems and web apps. Everything is GitHub at the whims of a UX designer that did some “research”.
> Absolutely nobody is using GitHub exclusively from their phone.
As an OSS maintainer, I do quite a lot of issue triage and simple PR review via the GitHub mobile app, which has gotten better by leaps and bounds in the past 3 years.
> I have never ONCE struggled to input my address into a form.
The different ways forms treat secondary addresses can be a real pain, if you have one of those.
I don't regret posting my comment (on Sept 4, not shown by default) because it truly was a shit change, but finding a viable alternative to GitHib has definitely elevated in my "get around to it" pile as the preferable alternative to ever giving feedback again. It just exposes how much else interferes with getting things done.
How do I make the comments stop? It's noise at this point. My comment isn't in my own account page under "contribution activity". There's no way to search for the comment in the actual discussion thread and trying to search page source for e.g. the username doesn't do any good because not all comments are shown by default; changing the sort to "top" doesn't work because, even though I only got 2 upvotes (and 1 emoji), the initial display still hides the majority (221 out of 251) of items to display lower priority stuff at the bottom... and besides it's broken and threads aren't sorted strictly according to any interpretation of "top" I can muster.
> But our HTML, CSS, and JavaScript runs on several major versions of each major browser
How freaking bold this mofo is! I stopped using GitSht because after being bought by MS it went downhill progressively rendering every crucial feature unusable! Like on purpose, simplest things like buttons and menus went more and more broken. Month by month SOMETHING new went wrong. How f* sinister can devs be to enjoy torturing users so much? Oh, right: this is a corporate policy.
I have 3 browsers that are possible to run on my system and NONE of them fully works with GitHub. When even on PaleMoon issue comments started glitching I gave up on GH. F*k it. I'd rather run my own.
That's basically the life story of the life of frontend engineer nowadays isn't it?
The lower I went to the ground, e.g. backend, then native code, then C... the happier I am. It's like the ocean, the lower you go, the more stable and calm things are. On the surface, you get the crashing waves.
I used to be a Web expert, from the early days, DHTML and flash, to the median years, jquery, backbone etc. to then writing my own libraries. Vue 2 was the last I really used as front-end heavy.
Since then I've been secluded more towards the backend, I leave the front end to the young. I do like systems like Laravel Livewire though, it's mildly sane.
When I write websites now, I do it all by hand and focus on really fast page loading times rather than a monstrosity of generated code and async over the wire. I have such a better time doing it.
Today's web should be considered harmful to the health. It's a high blood pressure job.
I really love firmware for this reason. Each instruction you send to the CPU means something. If you want, you can rip back all the abstraction and just run raw assembly. Sometimes the compiler can be very wrong and you get to embed the correct assembly in your C and suddenly the program is 10x faster. True story!
Trying to fit my application in 1kB of flash and one hundred twenty-eight entire bytes of RAM taught me a lot as a young programmer. It really makes you confront the physicality of the machine your code represents. I don't think nearly enough programmers have that experience
I’ve actually found it to be pretty nice and relaxing. Trying to customize a prebuild system where you don’t have perfect control over all the components is stressful to me, but I may be in the minority.
> Which is all to say, that mobile is the new baseline. And we’re trying to match it using a technology stack originally built for displaying documents!
This is such a bullshit take. I don't think I ever used my phone to do anything on Github. Nor do I want to.
Ironically, the blog doesn't work well on mobile. The width is fixed and the end of the sentences are out of view. I have to vertically scroll right/left to read
Yup, that's on me. As noted elsewhere this was my first attempt at converting Keynote slides into HTML (using https://github.com/mcfunley/better-keynote-export). I've pushed a fix for the overflow.
I looked myself about 6 months ago and it's not clear whether that's true or not.
Which probably doesn't bode well for AZDO as it's not a definite no, but on the other hand it's not clearcut that they are actually pushing that.
The general consensus among the great unwashed is that AZDO is turning into an undead project that won't improve. But the reality is there's a lot of present enterprise investment in AZDO and no clear migration path, as well as a lot of internal MS use of AZDO, so it's doubtful it's true but more a loud PM in GitHub over egging his own product.
But it's sort of turning into a self-fullfilling prophecy as people are getting skittish about investing in AZDO.
The reality is that unless you have crazy builds switching is a few days work and more a pain in the ass than a real project.
The whole design of AZDO is Enterprise-focused, and for example you have the capability to customise every little thing. It has a plugins API so you can add renderers for custom file formats.
The design is such that even if you have 100 active repositories, it is easy to use.
GitHub has no such vision. The interface is clean and easy to use, but the depth of customisation is nearly nonexistent. And the interface keeps bringing you back to the public area of GitHub.
Would be very disappointing if they killed off AZDO. I don’t think GH is an alternative, at all.
Will GitHub ever change the file list preceding the README.md content? This has always seemed a poor default, but maybe the way I use GitHub is different than their primary user?
Github project URLs are the defacto landing pages for most software components, both public/opensource and private/internal. It's reasonable to lead with the documentation.
Why should Github change the UI just because those people are trying to jam square pegs into round holes? Github is version control first and foremost, not a web host.
I appreciate that "README first" is useful when browsing projects, but it's significantly less useful when actually doing development. The "source code first" approach that GitHub took was one of the major differences with everything that came before it, and in my opinion one of the major reasons for its success.
I think this is a problem solved by github pages. If a project's primary distribution method is github, they should build a Page and link people to that, instead of the repo.
It would be nice to have the option, I think, possibly as a URL parameter. This opinion is somewhat self-serving, as I use the GitHub repo front page as the link for all my FOSS projects, because it's super easy to have the documentation track the revision of the code you're looking at. But it does also reflect where I typically look first when looking at other people's projects too.
(What would suit me, I think, is a view that was very much like the current one, but with the files list collapsed (but expandable). So there'd still be all the the tab-like row across the top, and the About column with releases link, and the main area gewgaws like branch dropdown and some indication of the most recent commit. But just with the README front and centre by default.)
You probably use it the way many users do, and I wouldn't be surprised if that happens someday.
But it's mostly just a sign of how almost nobody actually cares about the code now, and just use GitHub as a source of free libraries that may as well not have source available at all.
For others of us, a README is something we may briefly read once or twice when first considering or integrating a project, but the repo's code is where we spend way more time -- evaluating quality, tracing potential bugs, unearhing quirks and overcoming sparse documentation, considering whether a fork is needed, etc
But that's all hokey old greybeard stuff these days.
This website is a step back. One cannot say if there are some slides (presentation) with handouts (??) or something else.
> Which is all to say, that mobile is the new baseline.
I'm sure a lot of mobile users browse github.
Phones and tablets are a wonderful development environment. Notice the diversity of code editors and debug tools running on the phones and tablets. /s
That number seemed surprising to me - I actually expected the portion of mobile-only internet users would be significantly higher than that.
Turns out the 15% number means something slightly different. From that Pew Research page:
"Today, 15% of U.S. adults are “smartphone-only” internet users – meaning they own a smartphone but say they do not subscribe to a home broadband service."
So the 15% is people who use the internet exclusively via LTE/5G without paying for home broadband.
(I'm surprised that number isn't higher as well.)