Imho, this is were alternative layouts really shine: comfort, health.
Typing speed is an overrated fad (and in the worst cases an e-penis length contest) as in most cases when writing stuff (be it fiction, reports, code) your throughput isn't limited by typing speed.
Avoiding injuries on the other hand is invaluable.
saying it doesn't affect code writing speed is incorrect imo- after you've laid out your algorithm in pseudo code being able to quickly type it out is invaluable time savings. even if you try and automate it all away with shortcuts and refactors it still takes time to press those shortcuts for someone who's familiar with the keys and able to maximise their APM(actions per minute)
From what I see, Blizzard is slowly rolling out everything they need to eventually get rid of realms entirely as separate technical entities.
Cross-realms features are everywhere, the concept of PvP servers is no more, and if they manage to upgrade the auction house system to something more global, realms will be mere namespaces and players will be able to seamlessly play with all other players from their region.
Cross-realm guilds would be a big one. I was in a mythic progression raiding guild during Legion and recruiting was always a mess. I didn't play on one of the "top" servers for raiding and there just weren't enough quality players to go around. You'd have a handful of solid guilds at the top and everyone else would struggle to complete a tier before the next tier came out. And then in the middle of the expansion when player counts drop it got even more difficult to recruit. If you made the mistake of creating all your characters on a "dead" server you'd be looking at several hundred dollars at least to transfer them all. Cross-realm guilds are a long time coming.
Yes, I didn't mention it in my post because I think the auction house and the underlying economy issues are going to be the hardest part in making everything cross-realm, but cross-realms guilds are highly desirable. Your arguments are on point.
You don't need to run arbitrary third-party software to run ads, period. I'm perfectly fine with ads in an ad-sponsored ads but I'd appreciate if it didn't open my computer to malware infestations.
That would be neat, browsing through several dozen fonts to find the right pick is a bit overwhelming, although one can argue it's a self-imposed burden.
Isn't the iPhone more power-efficient than many Android counterparts? That would explain why they can afford a smaller battery (but may not explain all the gap).
Google Play Services (on Android) is not a search engine or a browser, either.
Google Home does not serve ads, either.
My original comment's grand-parent did not claim if Electron was a browser or a search-engine, or if it showed ads, just that it is not necessarily independent of Google services just because it's built from Chromium.
* It has built-in authentication and ACL, you get to choose who sees your stuff or not (not counting overarching privacy issues).
* It has built-in syndication, which means that it's easy to follow everyone's updates.
* It has discovery abilities that helps finding people you want to connect to.
* It has group conversation.
* It has event planning.
Personal pages have none of that, except with syndication where RSS is a partial solution. And on top of that, Facebook is providing it free-of-charge (with the "hidden" cost of scattering your personal data all across the universe) with very minimal setup, including for laypersons.
Exactly. People want to be connected, to have a kind of collection of people at their fingertips. Check what someone's been doing, send them a message. They want to share their memories and experiences. And they want the addictive qualities of Facebook... the likes, the comments, the feeds.
All of that is a social network, which is not a personal webpage.
You could create federated pages with these features using the following:
- web pages with comments and pingbacks
- wysiwyg editors
- photo albums and photo editing tools
- blogging
- direct messaging (xmpp/jabber)
Then, you could create individual social network portals that you could authorize to syndicate your federated web site. They could also host your website themselves. And each could offer unique tools, such as tools for event planning, or to help musicians promote their music (MySpace, anyone?). But the idea would hinge on multiple of these popping up at the same time, owned by different start-ups, which could be tricky.
> Facebook is a bit more than just personal pages.
I'm going to argue on the following points based on observations.
> - It has built-in authentication and ACL, you get to choose who sees your stuff or not (not counting overarching privacy issues).
Almost nobody knows well about how to control who see what, and even when they do, hardly anyone changes it often. Almost everyone leaves it at something that may not be appropriate for all the content they're sharing. Facebook, after its many privacy blunders, reminds people about the audience setting sometimes, but I don't see people changing it. Also, "lists" as a concept to control who sees what was stillborn. Less than a fraction of a percentage in my circles would even be aware of it (this despite me trying to educate people about privacy).
> - It has built-in syndication, which means that it's easy to follow everyone's updates.
Here again, it's easy to follow updates that Facebook deems the best to keep the person coming back to show more ads and make more money. Almost nobody knows how to choose to see someone's posts always and how to avoid someone's posts short of unfriending them. The default is users not knowing that they can control it, which means practically they don't control what they see and what they don't see.
> - It has discovery abilities that helps finding people you want to connect to.
The same argument in the previous point applies here too. Facebook focuses on making people come back often. So the discovery feature may be useful in some cases, but usually it tends to create an overload of people, groups and pages to connect with. Search on Facebook is dismal, and the main "discovery" mechanism is Facebook's suggestions (which is incentivized for ads).
To summarize, Facebook's features work to maximize holding people's attention on its platform and showing ads. How well this matches with one's individual choices varies a lot. Facebook isn't really doing anything phenomenal in surfacing relevant content to people.
As a counterpoint to your counterpoint, at least Facebook's default setting is friends and friends of friends (I believe, it's been a while since I've had mine on the default setting). By default a personal website is public, and it'd be pretty difficult to setup authentication and user accounts for the people you want to be able to see your content, keeping it secure and preventing it from leaking. That is a pretty huge difference. Not arguing Facebook has been perfect, obviously they've had huge blunders, but it is vastly simpler and more secure (most of the time) for the average person compared to them trying to do it themselves.
>Almost nobody knows well about how to control who see what, and even when they do, hardly anyone changes it often.
To be fair, that's true for most permissions on UNIX/Windows for the average person. Having a flexible ACL system that is user friendly is likely impossible. Either you make it friendly, but reduce its capabilities, or you make it complex and provide flexibility.
I agree that Facebook's implementation of those features is piss-poor and your analysis is on point. However you can't expect something to be a proper Facebook alternative with them missing.
It was unclear to users what they consented to when they signed in. Because Facebook doesn't give a damn about proper consent. The fact that Facebook botched it up is not less problematic than Facebook selling data because the outcome for users is more or less the same.
Turns out "move fast and break things" is a shitty policy when it comes to privacy concerns.
>The fact that Facebook botched it up is not less problematic than Facebook selling data because the outcome for users is more or less the same.
Users signed in to services they already had accounts with, and therefore trusted, knowing they were enabling features they wanted to use with their data. These services were hand selected big name companies. This is a far cry from selling data to the highest bidder for profit.
I think this might be part of the problem. The idea of handing over your private messages to some random company is so absurd that the average person probably assumes that it couldn’t possibly be what they’re asking for. You’ll have to make the permission prompt really explicit to overcome that.
Yes, but that doesn't mean that they consent to Facebook using that data. Whatsapp for example asks "read SMS" permission to verify your phone number. It also requires access to your contact list or else everyone's name will be shown as a phone number.
The average user seems to assume that the information is used to provide the service and nothing more. The last person I asked if they were worried about how much information FB has about them replied something among the lines of "Yes, but it's only things that I deliberately chose to share." (paraphrased)
To give a counterpoint, the lack of basic algorithmic knowledge of a developer in my team cost us a nasty production performance bug.
I agree that whiteboard algorithms are not exactly our typical day work, but I'm fine with them being "foundations", things at back of your mind and you can conjure when needed.
If a single developer was able to cause a 'nasty' anything, your engineering process is completely wrong.
It should have been caught at architectural discussions.
It should have been caught during performance benchmarking.
It should have been caught at code review.
Didn't do any of those things? Don't blame the developer. No single individual encompasses all knowledge required to adequately address all of your tasks. Someone with the foundations you want could just as easily have fucked up something else.
The retort to this is usually along the lines of “we are moving fast and need people to write 100% correct code”. Perhaps that’s the case, but the solution is to put guidelines down (api review, unit testing, etc) instead of demanding people be infallible.
In this case a reasonable test case beyond “Did it compile?!?” Would have caught this.
In this case the two points where we should have caught the issue would have been:
* Integration testing with a specific data set that was different from actual production data.
* Code review (they're not systematic yet but we're working on that) because the faulty code had a sketchy section and the conversation around it would have lead to a better version (that's what actually happened when fixing the bug)
My intent was not to blame the developer, I'm aware of the context they work in and as you have guessed correctly our engineering process is fucked up in many way.
The developer writing the correct implementation was just the earliest point where it could have been avoided in this case, I didn't want to frame it as the developer's fault, but simply wanted to say that some algorithmic knowledge still comes in handy.
My original comment wasn't clear enough about this I confess.
Typing speed is an overrated fad (and in the worst cases an e-penis length contest) as in most cases when writing stuff (be it fiction, reports, code) your throughput isn't limited by typing speed.
Avoiding injuries on the other hand is invaluable.