54 karma · joined September 3, 2016
This guy's not writing an opinion piece about which brand ketchup tastes best. He has published an opinion piece in which he speaks authoritatively about matters related to the domain he claims he's a world expert in.
As for the harmless exaggeration, it's not harmless. It's poison to my chosen profession.
Without spending more time or having some domain knowledge of his problem, I can't really comment on the architecture setup/choices.
and I just thought, hmm, here's this guy with ~5 years of ~professional dev(mainly with iOS) and he self qualifies himself as world class.
Looking at his bio, I see he's worked for 3 companies doing quite ordinary things.
I would love to know what gave him the confidence/ignorance to describe himself as such.
Building simplistic data driven UIs is (relatively) simple.
However, the issues arise as these get more complex. Instead of just needing to understand a thing, you now need to understand the engine which builds that thing.
Looking at the react community where the new hotness is also data driven everything. UI definition (incl. CSS) all now detailed in JSON(which each original author custom builds), a lot of time without constraints(..'cos flexibility)
Building a data driven anything without having a very strong focus on debug-ability right from the get go is doomed to fail.
My opinion is it's not okay. Why would it be?
every app now wants to notify you about everything.. so every phone i get, i need to go in and turn off notifications for everything bar calls & text messages.
Pity they don't sync your preferences when you get a new phone.
I'm pretty sure there would be a noticeable(couple of seconds) lag between both incoming & outgoing audio to the VM making smooth flowing conversation near to impossible.
salaried workers being exempt from paid overtime in most European countries has turned in to a joke. Instead of just being used to deal with "emergency" situations, it's used to coerce extra work for free.
If his name was France, his use of the domain would have been more defensible(depending on what he was doing with the domain).
in matters of UX...
Do designers who design webpages/apps generally call themselves GUI designers?
A calendar is not good for pre-determined dates where the date is fixed before hand - i.e. you don't get to choose what value you want the date to be.
For example, if you're entering in your driving license details for insurance quote, you don't get to choose when it expires - that's already decided for you. Ditto for DOB and other such things.
So, there are far more efficient options for date entry ranging from single text input (with appropriate parsing/validation) or the '3 dropdowns option(D,M,Y)' which is more effort but easier to avoid mistakes with.
> you seem to be using a particularly narrow definition of "designer" here
My definition of UI designer is somebody who designs UI (which encompasses those of print background which a lot will probably have been at some stage in the/their past)
> but it's mostly orthogonal to their role as programmers
No, it's not, unless your programmers have been relegated to code monkeys. In years gone past (pre web dominance, when native desktop applications ruled), developers were designers/user experience etc.. which lead to the checkboxes everywhere UI.
Good UI needs someone with good design aesthetic. This is where UI designers shine.
In contrast to other design fields(most notably Industrial Design, where designers have pretty much always owned (& thought about) design & interaction as a whole), that is not something which UI designers have done. It's only in recent years that I've seen UI teams claim UX in the form of renaming themselves as "UI/UX team". My point is that UX has not historically been something they've put much thought into ,and as a result, they are not qualified to just own UX.
No, it's not.
A designer making that mistake isn't a signal s/he is a bad designer. I've worked with UI designers who range from good to excellent when it comes to design.
Thus, my overarching point which was that UX ≠ UI
and that UX shouldn't be co-opted by UI teams.
Whoever owns the UX should be putting the thinking effort into how that behaves. Things like this happen due to a) inexperience with whatever UI construct is being presented and/or b) not enough thought being put in to the usability of that component.
A developer is generally going to be more hands on with the resulting UI (checking/testing etc..) Whereas, a designer has more than likely mocked it up in InVision/whatever and then done surface level checks
And product managers will be hands on with the product but, well, they shouldn't be trusted with UI/UX/anything but the description of the problem they want solved :-)
The more empowered a developer is to over-ride a designer/biz person's preference[1], the better it is for all.
Way too often, I see developers just accept what the product manager/designer specifies with zero pushback when it strays outside what could be considered the 'norm' for whatever tech stack is in play.
[1] I use the word preference because that is all it is - their preference. They don't have a magic ball.
Sidenote: I'm also seeing a rise in UX suddenly becoming owned by the UI & product management team which is bizarre. You have designers(whether from print backgrounds or whatever) making poor(& I mean piss poor) UX decisions because they don't have the exposure/understanding of web platforms. Case in point: if your UX person has a calendar widget to enter a date of birth, they should no longer be allowed do UX.
/rant
people who have natural leadership qualities can facilitate without thinking it harms their worth. too often, unsuitable people will be thrust into a management/leadership type role just because there is a (sudden, genuine) void that needs feeling(sudden growth /sudden departure).
Interviewed by a precocious child who didn't have interview skills.
have a clear defined arc lasting ~3 seasons with 6/8 episodes in each season..and then just stop.
point in case, house of cards should have been a 2 series show with frank never becoming President.
Add this action to notifications on Android. Then, I'll consider a business a/c.
Not every OTA is just a proxy. Some maintain their own stock and do forecasting/yield management etc..
Well, REST is architecture. Protocol Buffers are (de/)serialization.
I've tried it before (& although it has the properties I like[language agnostic schema definition..]), it was finicky to get working with of one the biggest IDEs out there(IntelliJ IDEA)
Also, it doesn't support Kotlin yet.(Java interop only option)
The only place I can see Protocol Buffers being useful is inside Google..cos it was a pretty crappy dev experience.
And I would be pretty confident in saying that not many Googlers/ex-Googlers outside Google use it. Cos if they did, somebody would make the dev experience much much better.
I'd be more inclined to say one of the main roles any manager is facilitation more than anything else. Any manager that "sets convention" is somebody who wants the easy part of technology without the corresponding hard part.
Talking about technical solutions is easy. Implementing it is much harder.
I've come across multiple "technical managers" who were hands on with code greater than x years ago and they always end up talking out of their arse. And that's not to mention the numerous wrong choices they've committed to/spoke about at a high level meeting with zero notion.
I don't think I've ever had trouble helping people to grok the implementation/architecture/whatever of any system I've been involved in.