Rethink of the Coda toolbar
One thing that's bugged me for as long as I've been using Coda is the toolbar. It's never entirely clear what's supposed to happen when you switch between one of the seven "modes" (five, if you don't count "sites").
Switching between "Edit" and "Preview" (for HTML) or "Edit" and "CSS" (for CSS or CSS-embedded-in-HTML) makes perfect sense. What's supposed to happen when you switch between "Edit" and "Preview" for a CSS file? What about "Edit" and "Terminal" or "Edit" and "Books"? Switching to either "Terminal" or "Books" has nothing to do with the file you're editing, really—it's all about the site overall Is there an implication that you can switch back and have preserved state? Given a tabbed interface, is it really worth being able to flip between an editor and a terminal within the same tab when you could just have them side-by-side? When you create a Terminal session and go back to a tab, is there any way to know that your session is still running in the background?
To my mind, I think it's worth splitting the six buttons into three groups (for want of a better term): global context (containing "Sites"), file mode (Edit, CSS, Preview) and "extras", which would cover Terminal and Books. For Sites, Edit, CSS and Preview, the buttons would do exactly what they do now—although there'd be a clear logical split between Sites and the others. Some sort of visual indicator that switching to Preview will actually preview the file you're editing specifically (which wouldn't apply when editing a CSS file) would be a nice touch. Option-clicking any of them would behave exactly as they do currently, except that they'd default to operating on the file you're working with, rather than a blank one: I'd be sorely tempted to relegate the current option-click behaviour to shift-option-click.
Terminal and Books would behave a little differently: if there was no Terminal or Books tab open, a new one would be created (as though you'd option-clicked by current behaviour), but if there was one open, then it would switch to it, unless you option-click. In other words, clicking causes "switch to existing, creating if necessary" whereas option-clicking is "always create".
Obviously, I can rearrange the toolbar to suit what I believe is a more logical way of thinking about the workflow, but I can't change the behaviours themselves. Don't get me wrong, I do really really like Coda, but this aspect of it bugs the hell of me :)
(The absolute ideal, of course, would be if plug-ins could add additional "file modes" and "extras" in a supported way, but I suspect that one'll be a while coming!)
Switching between "Edit" and "Preview" (for HTML) or "Edit" and "CSS" (for CSS or CSS-embedded-in-HTML) makes perfect sense. What's supposed to happen when you switch between "Edit" and "Preview" for a CSS file? What about "Edit" and "Terminal" or "Edit" and "Books"? Switching to either "Terminal" or "Books" has nothing to do with the file you're editing, really—it's all about the site overall Is there an implication that you can switch back and have preserved state? Given a tabbed interface, is it really worth being able to flip between an editor and a terminal within the same tab when you could just have them side-by-side? When you create a Terminal session and go back to a tab, is there any way to know that your session is still running in the background?
To my mind, I think it's worth splitting the six buttons into three groups (for want of a better term): global context (containing "Sites"), file mode (Edit, CSS, Preview) and "extras", which would cover Terminal and Books. For Sites, Edit, CSS and Preview, the buttons would do exactly what they do now—although there'd be a clear logical split between Sites and the others. Some sort of visual indicator that switching to Preview will actually preview the file you're editing specifically (which wouldn't apply when editing a CSS file) would be a nice touch. Option-clicking any of them would behave exactly as they do currently, except that they'd default to operating on the file you're working with, rather than a blank one: I'd be sorely tempted to relegate the current option-click behaviour to shift-option-click.
Terminal and Books would behave a little differently: if there was no Terminal or Books tab open, a new one would be created (as though you'd option-clicked by current behaviour), but if there was one open, then it would switch to it, unless you option-click. In other words, clicking causes "switch to existing, creating if necessary" whereas option-clicking is "always create".
Obviously, I can rearrange the toolbar to suit what I believe is a more logical way of thinking about the workflow, but I can't change the behaviours themselves. Don't get me wrong, I do really really like Coda, but this aspect of it bugs the hell of me :)
(The absolute ideal, of course, would be if plug-ins could add additional "file modes" and "extras" in a supported way, but I suspect that one'll be a while coming!)
3
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?I just finished writing a blog entry about this very issue!
http://stevenf.tumblr.com/post/814915...
1 person thinks
this is one of the best points
-
Inappropriate?I'm glad (but not at all surprised!) that you fine folks have been thinking about it too. I'll be looking forward to 2.x :)
I’m cheerful
Loading Profile...



EMPLOYEE