Am I the only one that found staring at orange hard on the eyes? I guess I should give the author credit for all the work that they put into this rant, seems like a blog post could have done just the same without all the fancy graphics and what not.
“Still, the author calling HN posters Neanderthals was a nice touch.”
In this case quite appropriate, though. Having to scroll down one third of the page before you get to anything resembling a meaningful discussion about the actual content of the article cannot possibly be a good thing. Neither can the sneer and arrogance displayed in this thread.
(I’m kind of aware of the irony of me participating in this thread. Resisting the temptation to be self-righteous on the web is hard.)
The "sneer and arrogance" displayed in the thread is from people who actually already implemented most of these features, and from people using those extensions.
This article boils down to "It isn't pretty enough, and I didn't write it." In other words: no actual relevant content. Just a lot of pretty images as text, BIG FONTS, and whining.
Mine's roughly that; the orange background is only a bit eye-straining for me.
For a lot of people with weaker sight, or outright visual disabilities that fall short of blindness, this would be entirely unreadable without Readability or similar tools.
Something that stops people from getting to content is noteworthy.
Other people thought it was worth talking about with regards to a blog post by a guy who makes a point of giving each post a unique, custom design.
The color choice also hasn't been the only thing criticized - the layout is cluttered and confuses some people. It's overall a much poorer design than many, if not all, of the other posts on that site.
Really? That’s where you want to go? It’s the author’s fault that people here talk (mostly) rubbish for trying to make his post look great (even if he falls short)? I don’t quite follow.
Lose the ego-investment/chip on your shoulder/BS. Nobody's impressed, and this isn't a schoolyard.
Where I "want to go" is exactly what I said. People will talk about the design first: how much they like it, how much they don't like it, whatever. We are not robots, and those of us with normal vision will pick up on color, shape, and arrangement before they read any of the text.
Simple rule: if you're going to be offended at people talking quite a bit about the striking color (or other design element) you used for your web page, whether appreciatively or not, don't use that striking color.
Well actually, those are title pages, but I've read those articles and I can attest that the different designs set a suitable mood for the topic at hand.
I applaud web publishers for taking up this paradigm and applying what publishing graphic designers have been doing for some time. Of course with most methods of design, it depends if the occasion is suitable. Some online publications can do well with a consistent design: http://www.alistapart.com/
While others do well with differing designs, almost as if each posting of their articles is a treat for their readers: http://trentwalton.com/articles/
just like D.Curtis does, so good on him if he has inspired others to do the same.
If you happen to be on a mac, control-option-command-8 is your friend. Also, the readability bookmarklet does wonders for the appearance of sites like these. (And thanks to the people on HN who originally introduced me to these)
Ditto for if you go to Best Buy or any other non Apple store that sells Macs. They never know about this delightful key combo. </8 year old level of humor>
I wish I could say yes. I found the color scheme interesting and a nice refreshing change from "Everyone's Posterous."
But I guess there are people who will complain about anything that is different. The slight irony of posting a complaint against orange while you were surely looking at a band of electric orange is not lost on me.
(At least, I assume you're with orange. Has pg lifted the karma restriction from the custom color preference?)
There's also quite a difference between the orange on this site (a harsh electric orange) and the relatively mild and somewhat popular shade of orange on the article, so I think it's a wash.
I don't think that there's that much of a difference - The site starts out the same colour as the header, in fact, and fades gradually. The majority of the piece, however, is on quite bright orange.
I suppose the main argument was: “So what? Orange is not hard to read on. It sounds like you're complaining because you like to complain about different things.”
Appropriate contrast was maintained, the entire design was not overly luminescent. Since it was the background color it did not create a wicked eye-draw the way the banner at the top of our comment pages here do.
If you don't like unusual designs then you shouldn't read peepcode; a magazine format is one of their boasted mission statements.
I know people with severe visual disabilities. They have readers or tools to help them read things with far less objectionable layouts and designs than this one.
Saying every site has to avoid all interesting design so that people who are legally blind can—through supreme effort—read your page unassisted seems to be unreasonable at best and disingenuous at worst. Readability and screen readers and accessibility helpers and style removers exist for a reason and people who need them use them.
Huh. Have you actually managed to respond to any differing viewpoint here without wildly misrepresenting that person's remarks in a way that starts at disingenuous?
Dialog dies with good faith; when you try to recast what other people have said in order to argue with yourself, it's clear that you're not communicating in good faith.
When you lash out against anyone calling you on it, that's only confirmed.
This is part of Geoffrey Grosenbach's project to use a different design for each blog post; see http://blog.peepcode.com/tutorials/2010/about-this-blog. (Not that I'm endorsing the rather orange design, but that's the motivation.)
The site and the god awful grid background image (appears on doubleclick) was enough to inspire me to make a new bookmarklet.
My first impression, article aside, was that the site made baby Jesus cry.
Edit: In retrospect I think it was the combination of the orange and the grid background (I have a tendency to doubleclick on everything) that really put it over the edge for me, the main design isn't terrible.
I think the background grid is just supposed to be an aid to align things properly when they're creating the content, and not really meant for readers to see.
I doubleclick text and blank areas constantly I realize this probably drives people insane, but while I'm reading a paragraph I will keep doubleclicking to select and deselect the text over and over. Somehow it helps my concentration.. I do this with code as well.
That's why I have bookmarklets to disable the dictionary lookups and other what I consider annoyances on sites that implement those features on doubleclick and yes I've been told that I'm crazy on many occasions.
I do it so, when my attention gets diverted, I can quickly start from where I left off since it'll be highlighted. The obsessive clicking is because I'm obsessive.
i've written a plugin as well. it's extremely simple: it uses find (or globpath() if you do not like external dependencies) to build a local cache. matching isn't approximate but you get results on partial matches and can browse files in directories (something i really missed in some other solutions).
I didn't actually try to read anything because the orange/white/black layout makes my eye cry, so instead I just skimmed over to get an overview based on the design/layout/article organization alone.
At first, I didn't know if the keyboard thing was a banner with the blog name, the article title, or an interactive flash component. Then I saw random screenshots scattered without any text under and things made even less sense.
I started scrolling, but was greeted with four paragraphs of text laid on two columns, then a list of icons. Was this the end of the article and the icons are "share" buttons? No, wait, there's more paragraphs down there.
But are continuing from which column? I mean, the list of icons could be an ad and I'm supposed to read both left columns first, and then the right ones. But it could an article divisor and I should read the top rows first.
Then under it there's this three scenarios so crammed together that it takes some more fractions of second to realize they are different columns.
See? I'm completely lost and didn't even start reading the article.
Especially in this situation I think, when you are somewhat motivated to click the link by title. I'd hope hacker news readers at least have the patience to scroll down if they don't get instant content gratification.
"confirmed" by who? every blog post I see titled "the fold is a myths" follows the same path where there author lays out a bunch of opinion of why they think it is "honestly people scroll fine, honest"
every empirical study (like the one linked) seems to confirm that there is an obvious bias towards content above the fold.
Dont think its particularly important here, I was pretty impressed by his design and not everyone needs to stick to strict usability constraints, but still handy to know what they are.
Anecdotal evidence, but evidence nonetheless: We did some testing of how people interact with icanhascheezburger.com and found that most people basically just scroll and then click the "next page" link at the bottom.
I'm not sure how well does this apply here. Why does it matter if someone pays attention to what's below the fold? Most of the post will always be below the fold (because it's longer than what a normal screen can handle), so if you either read it or not. The web pages 'useit' people show as examples are of a slightly different type (comments / products).
The problem of this blog is that there's no vertical element which clearly shows that it's cut by the fold and you can find more content below. (someone argued that this is the general answer to most "below the fold criticism" but I couldn't find it right now)
Did anyone ever think that maybe the problem is the FILES?
Let me ask that one more time. Would people be ranting like this if there were NO FILES?
I still believe the "future of programming" is where your code objects are not arbitrarily mapped onto files in the file system, you just manipulate them directly!
A few Smalltalks and Lisps out there do this using image-based development. This is where it's at. If you can't use a image-based Smalltalk or Lisp to get your work done, then use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk IDE and are the next best thing if you're forced to use a broken file-based language.
If you just take "files" for granted and think that the UNIX design philosophy is the best thing ever, then accept your fate and stop bitching.
" If you can't use a image-based Smalltalk or Lisp to get your work done, then use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk IDE and are the next best thing if you're forced to use a broken file-based language."
I've worked in smalltalk, and yes it is an interesting way to work but images had almost as many problems as hey solved. primarily version controlling and syncing code were terrible (yes there were some tools, and yes they all broke on weird edge cases).
If forced to choose these days, I'd rather use files + git + (+ emacs + grep + ... ) than images, Images are nice as an additional dev time artifact, but I believe files are more natural than images for source code.
"If you just take "files" for granted and think that the UNIX design philosophy is the best thing ever, then accept your fate and stop bitching."
This is provocative nonsense. smalltalk, while hugely influential and innovative is hardly the ultimate superior dev env that some old geezers make it out to be. I think it is mostly "the lost cause" style romanticism.
That's just the thing, git doesn't give a shit about files internally, it tracks the content instead and uses heuristics to figure out the file metadata.
Files and their artifacts do show up everywhere in git's UIs, because noone's found a better model yet of exposing the content to the user.
I agree with your post. That said, maybe the problem is the text.
There are many artificial problems we create for ourselves by using strings for everything. Programming languages in particular have upper limits on expressiveness due to syntax issues. We can't easily annotate expressions or types with extra details without filling the screen with symbols; characters don't scale. Keying every resource with a unique human-readable string causes import conflicts, broken backwards compatibility, and hundred-line diffs - all in the name of renaming one function. Mistakes like ambiguous identifier-scope lookups, block structure/indentation mismatches, and operator precedence issues eat up valuable programmer hours repeatedly, in exactly the same way each time.
We've designed better languages to mitigate these effects, but we can only do so much. We can do static analysis to catch common errors and incremental compilation in the editor itself, but the heuristics can only work in a fraction of innumerable cases. Even simple syntax highlighting is intractable in many cases. If we programmed in structure with an AST-aware editor, whole classes of artificial problems would vanish in an instant. (To be replaced by the UI issues of a whole different paradigm in editors...)
Well, there are plenty of people working toward this, myself included. We'll see.
This is similar to the "browse implementor" or "find senders" in smalltalk, or "Find Usages" and "Browse Implementation" in IntelliJ (I use RubyMine). You navigate the code, not the files. I've found I can concentrate on the design of the software a lot better when I'm not also worrying which subdirs certain files are in.
Sounds like some people still haven't learned NetBeans or Eclipse.
Takes some time getting used to, -just like vim or emacs, but once you get used to the keyboard shortcuts you get everything the author asked for. No mouse needed: check, fuzzy search: check, paths: check, metadata: check, beautiful: check
It's interesting that Eclipse isn't even on the radar for a lot of developers (especially for Mac users, Textmate being the holy grail of IDEs). It's a solid, platform-independent IDE, completely open source, with thousands of man-hours behind it and lots of language-specific plugins.
Not so much over high latency trans-atlantic connections with low bandwidth, which is something that works perfectly fine with a terminal based editor.
You can always put your IDE workspace on a networked filesystem the target system has also access on, so you get similar results. Also SSH can be started inside eclipse for additional tasks.
No mention of ctags. I use that more than anything to navigate around files in emacs: M-. SomeIdentifier takes you straight to the definition. I hardly care which file its in.
Depending on the language, IDEs are often not worth the trouble. I was big Eclipse and then Netbeans user when I did Java dev. When I started working in C++, I used Eclipse for about two days before I went back to vim. The Eclipse functions I depended upon most in Java - navigation, autocomplete, and refactoring - just didn't work all that well in C++.
IntelliJ IDEA has exactly what the author implemented, but IntelliJ IDEA can also take about 5 minutes to start up, and takes up all your screen real estate. When you work in 5 languages on a regular basis and just want your editor to start up quickly, that can be quite a pain.
Netbeans? There is a drop down of all open tabs, but that can't be filtered. There is also a window which shows open documents but for some unfathomable reason it can't be docked.
The only navigation I can see for open projects is the tree view which is painful for large projects with files scattered across the project (e.g. web frameworks).
edit: Ah, I see. The article wasn't about text editors. It was about how file navigation (within whatever environment you use) sucks.
I was very impressed with Notepad++. I've switched to vim simply because I've been doing more and more work on remote unix machines - and it's so much easier to just open up vim through ssh. Now that I'm used to how to use it, I also appreciate how easy it is to get a dark color scheme that's easy on the eyes.
But yes - a big upvote for notepad++. Very lightweight and easy to work with.
I also use Notepad++ and like it a lot. It keeps things simple and just works. One of the coolest features is if you change a file anywhere, the changes are automatically reflected in the opened buffer.
It's almost like programmers write programs to help them get work done! And I thought you were supposed to solve problems by making a big orange web page whining about them...
"This article started with pain, developed into an idea, and ended up as an unexpected prototype implemented in MacRuby. I’m using it daily and am fine-tuning the interaction, visuals, features, and performance."
I'm not sure this matters for what I do mostly: Use Rails.vim where you are moving around typically with :Rmodel or :Rcontroller and splitting windows to see the implementation and test side-by-side.
Use fewer files. I try to keep the number of files and folders for a project to as few as possible.
Then you spend much less time opening and searching for files. As more people get involved with a project, you'll have more files, but you should make an active effort to keep the numbers minimized.
Here's a little script I wrote to give quick stats on a project's size:
Why? What does that have to do with text editing capabilities? The number of files depends (or at least should) on what you do, not on how bad your tools are. If you limit the number of files to limit the file-opening time, you increase the fragment-searching time in the gigantic-file-of-doom. Also you lose the possibility to make local one-file changes which are self-explanatory if you look at the VCS history.
I'm not sure why would I want to make my work harder just to make up for the tool's features...
> For most programming tasks, editing involves opening several files at once and switching between them (e.g. HTML/JavaScript/CSS).
His idea of a solution is for better file navigation.
My claim is that often the real problem is a bloated set of files and directories in a project.
I find when the set of files is small, opening and switching between them is much faster and more productive.
This applies particularly to the beginning of a project. As classes/files mature, then I recommend splitting them up into more files.
For example, when starting a new MVC project I'll create one models file. All the models go in there at first because the project will be heavily edited.
Once it's become more stable, I'll split it into a file for each model/class.
This way when you make small changes you'll have the VCS history benefit you mention, but often you don't really need that at the beginning of a project.
That didn't work for me with nvi or vim, it just says, "/usr is a directory". Does it require an extension? (I'm assuming your 'vi' is a symlink to 'vim', which is not always the case.)
Similarly, Emacs has dired, and in some extensions you can edit the file metadata in place and hit save to rename files, chmod, etc.
Right, I'm talking about vim. On Ubuntu, by default, my "vi" is vim.
I'm surprised it didn't work for you using vim explicitly. It works for me using versions 7.1.138 and 7.2.245, from fresh installs, by default, with no fancy configuration or add-ons.
When I run vim on /usr, it shows me a directory listing which I can browse and edit. I can create, delete, and rename directories and files right there.
I probably just don't have the relevant plugins installed. I installed vim on this computer for some reason or another, but I usually use Emacs or nvi.
Kate comes close to providing what he is looking for:
It doesn't do an x/y fuzzy search, or an x y fuzzy search though it does to single word search.
It colors files by how recent they were opened and by if they were most recently edited or just viewed (changing/reference code).
The file searches include folder names.
All navigation tasks work through the keyboard.
It has GUI beauty.
Typical designer. "Oh no, my text editor displays its status to me using text."
Yeah. Some people get their eye-candy feed from lolcat videos, and then use their tools for work. (My desktop doesn't even have wobbly windows! Just a 1-px red border! How can I get any work done that way!)
Also, I'm fairly certain that eproject gets rid of the "wall of text" that disqualifies Emacs. In a perl project, for example, I can hit C-c C-f to find project files, but the files are displayed as the names of their resources -- instead of lib/Foo/Bar.pm, I see "Foo::Bar".
Personally, though, I just "eproject-open-all-project-files" when I start working, and then just iswitchb to the file I want to work in. Usually, you are two or three characters away from any file you want.
I think your attitude is overly dismissive. At least, I'd have a hard time writing someone off as a "typical designer" (a bit of a tired stereotype) if they're experienced in both vim and emacs, let alone work for Peepcode. The author offered a sustained, reasoned argument for better navigation within projects.
I agree that as a programmer, I care about functionality and tools that get out of my way so that I can get my work done quickly and efficiently. But I don't think that means that everything has to look ugly (or better - that it couldn't be more elegantly presented).
I'm a Vim user, and rarely leave full-screen mode. It's a great app, but on large projects even with the Fuzzy File Finder plugin, I agree that navigating can be cumbersome. I'd like to try out Jamis Buck's "Fuzzy Finder Textmate" plugin that builds on this, but have had trouble getting it installed on both my desktop and laptop.
tl/dr: The author knows what s/he's talking about, and things can be pretty and functional, too.
I've gone through this process a number of times on different computers so I imagine that others will find this quite useful. Thanks for writing it up!
As an aside, I think you can just download the 2.16 version of fuzzyfinder from vim.org and it will work with Jamis' plugin. That's the version I use - love this plugin and I doubt I'd be able to use vim without it!
Look through the forks of fuzzyfinder_textmate on github - Jamis has stopped maintaining it to work with the latest FuzzyFinder, but other people are still working on their forks to keep it up to date.
The thesis of the article isn't "pretty > learning and thinking", and I don't think your distinction between the two is valid. User interfaces shouldn't be left to rot in the name of "learning and thinking". It's important to consider the way something looks and functions as it affects your ability to use it considerably. Form matters just as much as content. You can learn and think and have things be pretty all at once.
Furthermore, I don't think you're really addressing the core of the article. He mentioned the word "ugly" once, and it wasn't even the bulk of his criticism: Emacs doesn't provide all the features he wants. The "Metadata" icon was left of off Emacs, and he goes on to mention things such as searching on class and method names.
Everything he wants is handled by eproject and a tags table. (If you don't want to generate a tags table, just have something generate it for you in the background. I use the Perl-specific http://github.com/jrockway/editor-tags/.)
Anything, icicles, ido, ibuffer, and iswitchb, are also good tools.
Anything, in particular, seems to cover most of his wishes.
He dismisses the menu style that ibuffer / iswitchb use as ugly, and while I agree that their output is cluttered, I still find them vastly superior in practice to a one-file-per-line list. They make more sense with an editor that uses a minibuffer, though. (I use dmenu, too.)
Also, I think displaying the file extensions in lowercase would make them easier to visually disambiguate at a glance. Block of CAPITAL LETTERS hide ascenders and descenders, making every word a rectangle.
You don't use xmonad, perchance? It's the only one I know of that uses the one red pixel in the default scheme. I guess Awesome or the like might too, but I haven't used them in a long time. Tiling window managers are a great example of something that is less "advanced" but more useful.
And as far as I can tell, both Emacs and Vim can easily satisfy all but the "beautiful" requirement for him. I think he should just replace all of his requirements with, "a powerful and extensible plug-in system."
Command-T is a relatively new Vim plugin that does fuzzy matching on the entire path, giving greater weight to characters immediately following slashes or other word separators in the pathname. I've been using it for a few days now and can attest that it is extremely fast and seems to "know" exactly which file I want after just a few keystrokes.
I find its design very novel, but the mouse-centric UI is a dealbreaker for me. (I went back to Emacs.) If you're already using a Mac, you're probably a bit more forgiving of mice, though.
For file finding, I use FuzzyFinder with a shortcut to the recursive search. So far that and ctags been good enough that I haven't wrestled with fuzzy file finder textmate. The Command-T plugin looks neat though.
" vim-fuzzyfinder plugin
map <Leader>t :FufFile<Enter>
" start recursive search with a comma. see help for 'fuf-abbreviation'
let g:fuf_abbrevMap = {
\ "^," : [
\ "**/",
\ ],
\ }
I wrote a simple fuzzy file finder extension for Emacs that tries to address some of the things I don't like about IDO (namely the "big paragraph" presentation that this article tells about), but does much less of course. I use it myself all the time, and if it could be of interest to the readers of this thread, here it is: http://code.google.com/p/find-file-suggest
I'm so close to getting vim to be my ideal editor...7.0 for tab support, and ctags opens tags in a new tab, not a new buffer.
But I can't figure out how to search currently open tabs instead of opening a new tab no matter what; I end up with duplicate tabs very easily. So his 3rd major "what I want" point really rings true.
Your problem is trying to use the tabbar as a replacement for :ls/:files/:buffers. Stop, and learn what tabpages really are--work spaces, or view ports.
I'm suprised Geoffrey doesn't mention that you can switch between TextMate tabs without the mouse using ⌘1, ⌘2, ⌘3, etc. I navigate Rails projects through a combination of ⌘t (fuzzy search), ⌘n (move focus to tab n), and the occasional side-menu mouse click, which works well for me.
At the risk of ending anticlimactically, I plan to release it as a serious helper application with painless TextMate, Vim, and Emacs integration for a small fee (payable with PeepCode credits or free to Unlimited subscribers).
I find it funny that about half of the comments are about the "horrible" web design of the article.
If you agreed with the message you would never have wasted that much breath on it, but you don't agree with it, and you don't have any good arguments against the article, so "Too orange!" it is. :-)
