I was also considering buying "Domain Modeling Made Functional" but I read that it uses F#. Are you working with F# or do you think it will be easy translatable to any functional language?
Ask your parents or non-geek friends: Given the task of finding the files with the name ending with .txt which of the following two commands would you choose?
Looks like "find" is yet another command with the Examples section at the very bottom. I suppose that's the convention or something, but sometimes I do run into a man page with the examples at the top, and it takes a lot of effort not to jump up and shout "Thank you!" loud enough for the author to hear me.
The brain is a powerful inference engine. A few well-chosen examples can teach 95% of normal people 95% of what they need to know (numbers pulled out of my butt, 2016). Put good examples at the top and marvel at how many more people actually seem like they RTFM.
And if we're going to be using the commandline, I'd much rather the unixy
find PATH -name FOO
than the powershelly
Get-ChildItem -Path PATH -Filter FOO -Recurse
I mean "dir FOO /s" is simple and all, but powershell was created because cmd was deficient in many areas.
The blogpost referenced in the article is also stacking the deck a bit, as some of the 'complex' commands are normal commands, but with the verbosity turned up - the rsync command has three flags for increasing verbosity...
if you want things to be short. Since parameters can be often given positionally instead of named and you can shorten parameters as long as they remain unambiguous and there are aliases – it seems like you're stacking the deck a bit as well.
PowerShell has over cmd (and WSH):
- Consistency in command handling, naming and discoverablity
- A robust scripting language
- A modern shell
- An embeddable scripting environment (most GUI configuration stuff on Windows Server these days is PowerShell in the background; PowerShell is also the NuGet console in VS)
- Extensible
- The core of the language is built up from mostly orthogonal commands which work completely the same regardless of the context
- Interoperable with native commands, .NET, COM, WMI, arbitrary item hierarchies (file systems, registry, etc. – comes back to consistency and the point above)
- SSH-like capabilities built-in. Running a command or a series of commands over hundreds of machines is no harder than doing it locally.
The (perceived) verbosity can usually be tamed quite a bit with aliases and shortening parameters (or using them positionally), which is what you'd do most of the time when working with the shell once familiar with it. I guess you're not yet familiar with PowerShell or never used it, and that's okay. Because the long commands are in many, many cases self-describing to the point that you don't have to guess at all what they mean or do. This also helps with learning or communicating with others.
> I guess you're not yet familiar with PowerShell or never used it
This is correct - my example wasn't intentionally complex, but the result of googling and looking at the top answers (cmd was deficient, and I was wondering how you'd do the same thing in the 'proper' windows shell). I'm glad I have got the responses I did - I didn't mean to deride powershell, but show that if you want more power, you end up with more complex commands - and at the cli, I'd rather be typing in the unix example that the powershell one.
In any case, powershell should be better than the other shells we're talking about - it's from 2006, and the others are considerably older.
On the other hand, the power shell version returns objects that can be manipulated in a safe way, whereas the find version relies on "-exec" being a feature of find (Talk about bloat.), which is string-based (if you're not extra careful: breaks with spaces/tabs/newlines/semicolons/dollars/backslahes/... depending on what you use it for) and spawns one process per file (really inefficient).
once you mentioned it, the original commands which are compared are not equivalent. Dir does case insensitive search, find is case sensitive. The equivalent would be:
It's funny how minds differ. As a kid I was mesmerized by globbing and pipe operators. GUIs didn't have the same magic appeal. The List monad was calling me from the future past.
The original article states: "One of Python’s most visible users, Dropbox — who also employs Python’s creator Guido van Rossum — recently announced it has migrated major parts of its back-end infrastructure from Python to Go" and refers to [1].
From what I understand they want to persist the trained model in a language independent way, so you can train the models with whatever language or framework you wish and then save it to a format that can be used by any other language or framework to classify unseen instances.
I do not consider myself an hater (I have used both php and go). I would say the results on that page are consequence of php having more mature database drivers (written in C) than go, that is still in its infancy. If you look at for e.g. Plaintext it is more in line with what one would expect from a compiled language versus an interpreted one.
> It looks like the code viewing area was narrowed.
Doesn't look like it[1].
I'm not sure that a much wider github would be of use to me. Most projects usually place some kind of limitation on the number of characters per line and even in the file browser I don't find filenames long enough to take that kind of space. Maybe you have some other use cases worth sharing?
My team's inherited code (legacy code) where not all lines are trimmed to 80 or even 120 chars. Long file names or deeply nested directories aren't something I run into currently, but I recall running into them on several J2EE apps in the past.
Support is quick to reply but often there is nothing they can do. I've tried contacting regarding both technical problems and billing issues and in both occasions they couldn't do nothing to help.
> I don't care about flatness or skeutransmogrification or whatnot, but the damn thing must WORK.
Absolutely. I don't understand how so many people are focusing on the highs and lows of the UI but are ignoring serious UX problems like the one you pointed.
Apple says "Nothing we’ve ever created has been designed just to look beautiful. That’s approaching the opportunity from the wrong end." but then they change the perfectly readable Messages screen to a less readable one that has the only advantage of arguably looking better. And it's not the only problem IMHO.
On that screen used to be a send button that invited interaction. You look there and you know that it's "actionable". Now in the new version there is no button, only a gray text with "No Perceived Affordance" that looks more like a description than an "actionable" element. The most important "action" on that screen happens when you press a gray text on a gray background!
And the call screen? On the iOS6 one it was easier to read the name of the person who is calling because the white text is above a black overlay giving it enough contrast. On the new one the text although bigger is lighter (as in less bold) and is directly on the image. Light backgrounds (sky, clouds, etc) will make the text barely visible. Also how can I reject a call? There is nothing on that screen supporting the second most important functionality that is expected from it. Even accepting the call is now more complicated. The size and position of the elements makes more sense now but the text is lighter (less readable) and it's now more complicated to accept a call: before you only needed to touch accept, now you need to slide.
The home screen: even ignoring the aesthetics that I personally don't like, it's undeniable that the text is much more readable with iOS6. The small border and shadow made it readable with virtually any background. Also the icons were easier on the eyes, the new bright colors tire/irritate the eyes more. Also the relationship between icons and the functionality they represent was already hard in some cases. For instance for someone that didn't know Safari it was not easy to tell which was the browser and which was the compass from just the icons. Also the photos icon was not obvious at all and the Music vs iTunes Store icons are almost the same with different backgrounds but now it got worse: none of the exisiting problems got any better and at least reminders, settings and game center got worse.
Of course there are a lot of screens that got better imho. Music, contact view, the calendar, clocks, compass, weather...
> The most important "action" on that screen happens when you press a gray text on a gray background!
The "Send" text is gray because the input box is empty. When you typed in something, it will turn blue. Still not as intuitive as a button though.
> Also how can I reject a call?
It's exactly the same as in iOS 6. There've always been two different call screens since the first release of iOS. One is shown when your phone is locked, where you need to slide to answer and push the power button twice to reject. Another one is shown when your phone is not locked, where you have an answer button and a reject button. The screenshot causes the confusion because it is comparing the second call screen on iOS 6 with the first call screen on iOS 7.
You are completely right on both. I'm sorry, my mistake. Regarding the Send button, or lack of thereof, it is much better blue than gray but, as you said, it is not as intuitive as a button. There is a lack of perceived affordance. It's one of the top 10 mistakes in application design that Nielsen[1] points. Of course Nielsen can be wrong and Apple can be right.
Discoverability has taken a hit, try finding spotlight search, you have to scroll the home screen icons down. Something that makes no sense, and if you scroll from the top of the screen you get the notification centre.
I actually don't have anything to add to your comment, but I just wanted to say I agree 100% with literally everything you wrote here. These are my exact gripes with the new version, expressed better than I think I could have.
I hate posts like this that lay out some first-order criticism of a design as if the designers did not consider their obvious concerns. It also sounds like you are making judgements based upon screenshots without actually using the software.
As far as messages go, it seems that the contrast is appropriate for the bubble at the bottom of the screen. The presumption, I think, is that users will scroll to read previous messages and the contrast will be fine where they are reading. The contrast for old messages is reduced to reduce the distraction from content the user is not reading, since it has already been read. How often do you read previous messages in a conversation vs. the last message? This difference clearly has dictated Apple's design.
Second, the concern about white text above the photo not being readable is laughable. If you really think Apple hasn't considered the idea that some photos will have lighter colors I don't know what to tell you. If you watch some of the intro WWDC videos it's very clear that Apple has thought through very carefully the various automatic treatments and text rendering they are applying to ensure they are readable by the user. Any places where things are not perfect will be corrected later.
If you want to criticize iOS 7 you can do better than conjuring up things that would only be true if Apple literally had zero design skills.
That kind of thinking adds very few to the discussion. I respect Apple and I know they are a reference in terms of UI/UX. This does not mean however that they are immune to making mistakes. Your argument is, from what I understood, that as they are very good they must have thought of it and if they choose to do it anyway then it must be the best way. I do not agree.
Even for the message at the bottom of the screen there was more contrast before when the text was black. In a room it does not matter much but out, in the sun, you can tell the difference. Anyway, even if you read the most recent message most often than others (which is probably true) you often need to read the previous ones for context if the reply arrives some minutes or hours later. If you are out, previously you could read the last two or three messages without problems. No you have to scroll so that the previous message is under focus to be able to read. And what is there to be gained? Isn't the fact that older messages appear before the new ones not enough to hint about their order?
Again you raise the argument that Apple always knows best and therefore it's laughable that I point out such a thing. Of course Apple would never make such a mistake. Just look at both photos and ask yourself which one can you read best. Also look at screen of the (beautiful) weather app and see if you can check your signal or even the time[1].
Also do you think that yellow text on a light background is a good idea in terms of readability? Because that's the color of the "actionable" elements in the Notes app.
I posted it above but just to re-iterate if iOS 7 ships where background images render the status bar, text, etc, unreadable due to an obvious "white on white" or "black on black" issue, or at least if this isn't somehow addressed otherwise, then I will (figurtively :)) eat my hat.
I'd argue most of my beef with the armchair commentators is they are making what appear to be deep criticisms of iOS 7 without having actually used it, and without taking into account the fact that it's beta 1. They are shipping a new "letterpress" text treatment in UIKit, my guess is that they will apply this treatment to text if it is sitting on top of a similar-colored background, but probably have not worked out the details yet. I could see it being a reasonable technical and design challenge since you may need to apply a treatment to only part of a glyph. I'd ask the poster what their "duh, so obvious" solution is to their "duh, so obvious" observation. (Note: "leave the status bar alone" is not a valid answer here, since the design goal is to have the content in iOS 7 take up the entire screen. If you have a problem with that decision, argue that point, but realize it has nothing to do with status bars anymore. Even if Apple left this pretty glaring flaw in their design, they may have decided to do so because having content take up the entire screen is worth this cost, and the onus is on the critic to explain why it is not worth it, not that they are too stupid to have noticed this edge case.)
Basically if you see something and it's something that 99% of developers would identify as a potential edge case, you can be sure Apple considered it too and at least made an explicit design decision to deal with it or punt for later betas. If they made an explicit design decision, which is assumed, then you should try to understand that decision and then critique that decision and its tradeoffs beyond Comic-Book-Guy-esque "this is so obvious they are so dumb how could they miss my clever edge case I've discovered." Let's say Apple really do see that white on white is an issue, and actually decided to leave it that way and ignore the case altogether. Why would they do this? At least address this question if you are going to critique the design. The OP assumes it was an oversight, not a design decision or technical debt, which is kind of insulting to Apple designers and engineers.
I would prefer if before starting a complaint about text legibility, colors, contrast, and so on, if people would include a disclaimer of if they have actually based their opinions upon viewing the design on an actual device.
> The presumption, I think, is that users will scroll to read previous messages and the contrast will be fine where they are reading.
That's a wrong-headed and frankly stupid presumption on Apple's part, if true. You're arguing to make the top half of the messages screen unreadable (or at least more difficult to read) in the name of a gimmicky gradient effect?
> If you really think Apple hasn't considered the idea that some photos will have lighter colors I don't know what to tell you.
They haven't in the beta. Unless you set the image to be basically all white (in which the overlaying text turns black) the text remains white. Even on the default "live" teal background the text is hard to read. Hopefully this will change in the release, but considering promo shots show the lock screen as it is now, I'm not hopeful.
> If you want to criticize iOS 7 you can do better than conjuring up things that would only be true if Apple literally had zero design skills.
Wait, so you are saying that if Apple didn't employ "good" designers, his criticisms about the new UI would be valid, but since they do, his criticisms are baseless? Please go ahead and defend that logic, should be good for a laugh.
My issue is the OP fails to realize design is about tradeoffs, and points out where the new design sucks and where the old design is better, but shows his hand by not considering why the new design may be better. ("arguably looking better", what does this mean? Why does it look better? Perhaps there is a functional purpose to it that he/she is overlooking?)
The new message UI is obviously trying to fade out the older messages since, if you assume the latest message is the most important content by a large margin, older messages are a distraction. I am not going to say this is a wise design, but the blindness the OP has to this dynamic shows they are firmly in the "Apple are idiots" camp, without an attempt to see what is actually in front of them: tradeoffs.
As far as the white on white issue, it's obviously a bug or to-do. Mark this post, I will eat my hat if iOS 7 ships and there are cases where you end up being unable to read text upon user-defined backgrounds like the home screen or lock screen due to some obvious issue like light text on light background.
First off, I don't think they are explicitly trying to fade out older messages. The received message bubbles are gray and don't seem to have a gradient effect going on; it's only the sent ones which are colored (green or blue) and have the gradient. So I think Apple's goal here really was just a gimmicky gradient effect for the colored (sent) messages.
More evidence for that is that the bubbles themselves don't seem to change colors as you scroll; rather they are just sort of a mask for an underlying gradient layer underneath (so you can have one large bubble which fills the screen and is light on top and dark on the bottom).
But even if their intention was to make older messages fade out, it was still severely misguided. It is trivial to discern which messages are older (they are higher in the chain and therefore further from the text input for a new message). Users of iOS have been familiar with this for years (and isn't the new UI supposed to move away from explicit visual cues since the assumption is people are used to it by now?).
Moreover, it actually hurts usability, since users now have to scroll more often to get messages in the readable portion of the screen if they want to read through a conversation.
And, on top of all that, if there is only one sent message in the conversation, there is actually no way to bring it into the readable portion of the screen due to the snap-back! (Further evidence that this was intended to be no more than a visual gimmick.)
