Ah, the controversial hamburger icon. I have taken to calling it the 'Junk Drawer' myself because it is the place where you put everything that you can't think of a better way to represent in the UI. I think it has a place, but it is overused as a solution to create a clean UI because it makes it easy to meet the requests from different stakeholders to include a variety of functionality.
I find it interesting that they were thinking of it in a very similar way based on this quote from the article "In your garage organization, there’s always a bucket for miscellaneous. You’ve got nuts and bolts and screws and nails, and then, stuff, miscellaneous stuff. That’s kind of what the hamburger menu button was."
I hadn't even thought of this specifically, but after it was mentioned in the initial post I realized just how much that is my use case most of the time and how often I am fighting with google maps to accomplish what are relatively simple tasks like adding an additional point along a route. If you are trying to add multiple additional points on a route it gets even worse.
This is all much worse on the Android app as well, where it makes the assumption that your use case is to get from where you are right now to somewhere else. Trying to get from point A to B, where neither is where you are now, is unnecessarily frustrating.
> This is all much worse on the Android app as well, where it makes the assumption that your use case is to get from where you are right now to somewhere else.
That strikes me as a fantastic assumption. I wonder what percentage of routes involve the user’s current location? I bet it’s high!
I can't reply to eitland for some reason, but yes, I get both those boxes.
I open the app, click my destination, and then click "Directions". The very next thing is both of those boxes, with "current location" defaulting to the start location. I can then change that if I want.
It optimizes for my most common use case, but allows me to do it otherwise, too. I don't think I could design this better.
On android I just (from london) typed "Washington DC to New York" and it instantly popped me up directions for the other side of the world, with two editable boxes.
That is 9 or so manual steps and it doesn't become clear until step 7 or so that it can even be done! There's nothing intuitive about this and when someone knows how it works that must be because they've either learned it from someone or kept on experimenting with it until they figured it out.
compare this to the original that they "simplified" away:
- Open app in navigation mode (step 1)
- it shows two boxes, where you are going from and where you are going to
- fill said boxes. There is a button next to from to choose current destination. (step 2 and 3)
- click get directions (step 4)
Compared to the current "simple" version it is immediately clear and there are fewer steps and less things you need to know.
No it was literally 4 actions (3 if you accepted the default starting point) and the the same amount of typing the current solution. I didn't summarize anything.
1. Open app in navigation mode (there was a separate icon for that)
2. Accept default start or type if you don't want the default.
3. Point at destination
4. Type destination and enter
Besides it was immediately obvious when I opened the app for the first time on my first smartphone, it just made sense and still does when I think about it.
I exaggerated wildly and can get it down to 5 steps. It is by definition discoverable since we have all discovered it, but I hold that it is still not obvious or self-explanatory in any way.
It's immediately obvious to me how to use it now. And if you accept the default start then both solutions are still the same.
Gmaps right now works like this:
1) Open App
2) Click search box
3) Either select a destination from the list that pops up or start typing and actually search. Once that's done the route pops up with your travel time.
4) Click start
If you want to change your start:
4) Select the starting location
5) Search or select from the list that pops up and your route and travel time are show.
6) Click start
It's not rocket science. It's all obvious from the UI.
I relate to this and give a lot of credit to my father for teaching me work ethic that I never knew I would need at the time. School was easy and I never learned to work hard at academic work, but I sure worked hard finishing a basement, chopping wood, shoveling the driveway, and much more. I always hated doing that work, but I would see my dad just continue to power through any project no matter how difficult it got. I would always find ways to take a break, but then I would see him continuing on and get right back in there and help him out.
After getting out of school and finding out that it actually does take time and grit to finish a project I have been grateful for the example that he set. It hasn't been easy learning to work hard at something, and I don't do nearly as well as he does at it, but I have gotten better over time.
Its because of this that my perspective has changed greatly around what makes a person succeed. I help teach people programming in my spare time and one thing I have noticed repeatedly is that the ones who do best over time are the ones who just keep at it even if it is difficult. Too often the "gifted" ones do great at the beginning, but once they encounter a topic that they don't naturally get then they might just give up because they feel it is too hard for them or that they will never get it.
Being able to reach "flow" quickly when setting out to work on something is what matters, even more so than "work ethic" or "grit" alone. In the longer run, relying on the latter just sets you up for burnout and the stress of overwork; whereas the former is sustainable and even quite enjoyable.
Physical activities such as shoveling snow and chopping wood are good at inducing flow, whereas it can take some effort to reliably enter that state when doing something more abstract. I think this is why the Pomodoro method is so popular, it can be used to "gamify" all sorts of tasks since the regularly-scheduled breaks act as a physical marker of your achievement.
That's a good point and brings up something I still struggle with - "flow." I'd never heard it put that way but that gives me another tool to help me up my game. Thanks!
Pretty cool little tool. We have a product that is a combination of ASP.NET Razor views, Backbone, jQuery, and more as a result of several different partial transitions of the codebase. Sometimes it is difficult to figure out which framework is setting a given value in the UI, so I'm going to give this a try and see if it helps out.
I really like this idea. I use Pocket pretty heavily for bookmarking, but there has been something off about it and nearly any other solution that I used that I couldn't quite pinpoint. I think this is part of the issue. I save a set of bookmarks on a topic over a period of time, but it isn't easy to get access to all of those bookmarks again. Searching doesn't quite accomplish the goal because I might have been looking into a similar topic months ago, but a search will return results from both "mental sessions" together and I have to separate them myself.
I have tried saving all of my bookmarks also, but then I usually have to remove my pinned tabs that are part of my overall workflow and not part of the mental session.
Seconded. This is also a great read on how to track down a deep problem, going through all of the steps required to figure out where it was coming from. That's on top of it being an entertaining view of early computer networking.
Hot Exit is one of those features that I didn't think I needed or wanted...until I started using Sublime like a notepad to store text, but not save it. I'm excited that this feature is now in VSCode now, and it also works with files that have never been saved just like Sublime.
It's great to see other people's solution to these types of challenges in React. We have been implementing something similar for images because the existing components didn't meet our needs. I look forward to digging into your code and seeing how you implemented it.
This is a real problem in our industry. We all like to think that we 'know' how to write good code, after all we read 'Clean Code' once. That, combined with either overconfidence in our abilities or the negative perception that comes with not knowing the answer to every problem leads to a lot of software that has applied 'good' coding practices and architecture to produce a mess of awful code.
In reality it is probably a lot more like learning how to apply any other concept, it takes practice, yet we don't spend enough time practicing our craft. This is particularly a problem because in the course of developing a product you will only get to implement a new solution to a problem a few times at best, or once more likely. This means we don't get enough experience with the different possible approaches to really internalize what a 'good' solution looks like.
We spend much more time learning the software development approach du jour, XP, Scrum, Kanban, Lean, etc. It doesn't matter what software development approach you use if the output is an unmaintainable mess of code.
Honestly the best way to go about this, in my mind, is to make criticism ok in our industry. I've been trying my hardest to get someone I know to comment on my implementation of a CS280 homework I've been working on. I want to get to the point where I can properly write this code so it is readable to everyone. It seems like every time I ask someone to do this I'm told "Why would you want me to tell you how to code"
That's insane! I think that a goal of any programming course around the world should instill the idea that getting your peers to modify and read your code is a must in our industry. People need to be able to com along, see what you've done, and understand it.
If anyone want's to comment on my code that I'm talking about in this example it can be found here:
I've attempted to live up to what I think is "good code" but no one want's to tell me if I'm right or wrong or even discuss this for fear of hurting my feelings I presume. I always get "run valgrind or a linter on it" and I've done that and come up with no ways for improvement. Everything is all opinion and no fact in this business of code cleanliness although this should be a cornerstone topic for the software development industry.
Have you tried codereview.stackexchange.com? I find it can be a nice way to learn what others prefer and get tips for improving clarity especially in languages that I'm new to.
That's a hard thing to get. A lot of people will play shitty status games and make feedback to try to prove they're more clever than you. And since people do that, genuine feedback can often get interpreted that way.
That's a good point. There's bad code. And then there's that's not how I would do it code. Too often, in public the latter gets treated like the former. When you're still open to learning this is confusing. That is, do I suck? Or is that feedback coming from an asshole?
The thing that taught me the most was writing an application and having to maintain it for 4 years. You see where the pain points are (as you end up revisiting them often), and you have no one to blame but yourself. You learn from your own mistakes.
I also learn from other mistakes as well. I has a habit of inlining conditionals in python -
if False : continue
until I noticed that the same style made reading someone elses code harder. I didn't notice it in my own code as I was more familiar with it. When I did notice I stopped doing that.
Keeping the logic as close to the data as possible helps as well (ideally in the data schema if possible). I think Linus's quote about bad programmers worry about the code, good programmers worry about the data and their relationships is true for most of not all levels of the stack.
I watched the video of a Pharo demo linked in the article and it was amazing. I don't know how much of that capability comes from the way Smalltalk is built vs just a clever IDE feature.
I imagine this would be much easier to implement in a language with strong typing since the vast majority of possible matches could be ruled out with a simple signature check instead of evaluation.
Having a feature like this would be very useful when teaching people how to program since it would help answer a lot of the basic questions that get asked.
I find it interesting that they were thinking of it in a very similar way based on this quote from the article "In your garage organization, there’s always a bucket for miscellaneous. You’ve got nuts and bolts and screws and nails, and then, stuff, miscellaneous stuff. That’s kind of what the hamburger menu button was."