A bad workman always blames his tools. – Proverb
One of the biggest complaints I hear about designing in the browser is that designers do not have the tools they need to create good designs. Even though I think that mindset has many flaws in it, I want to focus on only one part … the tools.
While many may might not be aware, there are so many great tools out there to help create beautiful fluid designs within the browser window. These tools have been created by other designers and developers that faced the same issue. The tools that they have created turn an ordinary browser into a grid displaying, typography pumping, color blazing machine.
Gridlover gives you adjustable css for font sizes, line heights and margins. The default css output is for body, p and h1 – h4 headings, but you can of course apply your adjusted values to any element by editing the css later.
Adobe Color CC is a fun and simple way to capture inspiring color combinations wherever you see them.
Viewport resizer is a browser-based tool to test any website’s responsiveness. Just save the bookmarklet, go to the page you want to test, click on your created bookmarklet and check all kinds of screen resolutions of the page.
Typekit is a subscription font service that brings thousands of fonts from foundry partners into one library for quick browsing, easy use on the web or in applications, and endless typographic inspiration.
A web with web fonts is more beautiful, readable, accessible and open.
Google Fonts makes it quick and easy for everyone to use web fonts, including professional designers and developers. We believe that everyone should be able to bring quality typography to their web pages and applications.
When it comes to the web … this is a tool … so use it like one!
Available for both Windows and Mac, Adobe Photoshop is an extremely powerful application that’s used by many professional photographers and designers. You can use Photoshop for almost any kind of image editing, such as touching up photos, creating high-quality graphics, and much, much more.
When it comes to the web … this is also a tool … so use it like one!
Sketch gives you the power, flexibility and speed you always wanted in a lightweight and easy-to-use package. Finally you can focus on what you do best: Design.
When working on a client’s site, I usually have the privilege of having access to something like cPanel. From cPanel I then can access things like phpmyadmin and file manager. Using tools like this has always kept my life simple.
A problem arose, however, last week where I needed to get ahold of a database so that I could set up a local staging site. The issue was that the only credentials the client was able to give me was their SSH credentials. My gut instinct was to email them back saying that I needed more access, but then my inner adventuring self came out.
Over the last couple of years I have been pushing myself more and more to use the command line instead of GUI’s. The main reason for that is because I believe using command line gives you a better understanding of the things you are actually working on. This is what led me to my plan in this situation: to access the MySQL server remotely over SSH.
Luckily I work with incredibly smart people who I know if I don’t know how to do something, one of them will. Due to that I sought out one of the guys that I know is strongest in command line. In the matter of minutes he was able to help me get what I needed with only TWO COMMANDS!
In case anyone is wondering how to do this, please keep reading.
Before you Start
Before you start you will want to make sure you have the following information:
- SSH host
- SSH username
- SSH password
- SSH port number (if applicable)
- MySQL database name
- MySQL username
- MySQL password
Running the Commands
Once you have that information you will want to launch your command line application of choice (I prefer iTerm 2 for Mac). After you have your application running, you need to run this command:
The syntax is ssh <username>@<servername> -L <localport>hostname<remoteport> -p <portnumber>. The reason we use 3307 for the localport here is due to the fact that you might be already using port 3306 depending on your setup.
Things that you need to replace:
- username – this should be replaced with your SSH username
- host – this should be replaced with your SSH host
- (port_number) – this should be replaced with your SSH port number
Once you have done this you should be asked for your SSH password. When that comes up, insert your password and hit enter.
Now that you are in, in order to get a MySQL dump you can run:
Things that you need to replace:
- mysql_username – this should be replaced with your MySQL username<
- database_name – this should be replaced with your MySQL database name
- filename.sql – this should be replaced with the name of the file you want the data to be dumped into
Once you run that command you will be prompted for your password. This is now referring to the MySQL password.
WAHLA! You now should be able to find that file inside the current directory. In most cases that is /home/(mysqlusername)/(db_name)/. You can access this via SFTP.
In the End
In the end this was a great solution for me. I’m sure there are even more advanced command line wizards that know of even better ways to do it. With that said, this worked for me. I believe that due to the simplicity of it, it works pretty well. I hope you find it helpful!
In this screencast I introduce the purpose for the #OwnYourCanvas series. I then talk about the different goals for the web experience that I am wanting to create.
- Designing in the Open
- Responsive Comping: Obtaining Signoff without Mockups
- Time to stop showing clients static design visuals
Recently a debate that has been stirring is the question of: “Will web design soon be dead?” I think this is a great question and one that I plan on expanding on in later posts. In the mean time I have come across a jewel of a post written by Dave Rupert giving one perspective on this debate. You should check it out.
A few friends of mine have recently asked me why I have not taken the time to design my blog. I am a web designer after all … right? Whenever I am asked that I point them back to my original post: Get Off Your Butt (PT 1).
For years now I have been wanting to blog so that I can do my best at giving back to the community just as so many countless others have done for me. The problem was I could never find the time to design it, so I always made that my excuse for never doing it. This crushed me and so a few weeks back I did something about it. I went to WordPress.com and in the matter of 10 minutes I had a blog (Thanks to the Automattic team for being so awesome)!
Even though I have gotten into the habit of blogging, it does feel weird to be writing on a website that is not truly my own. Also, one thing that I have been applying to my workflow is designing inside the browser which is what inspired me to write Own Your Canvas: Learning to Design for the Web. The only problem with that is that it is really only big picture thinking and does nothing to really talk about how that is practically worked out. Not only that, I actually don’t think this workflow has really been fully laid out in great detail (more then a single blog post) by anyone.
With those things in mind I have decided to do something about it. I am committing myself to redesigning my blog, but even more then that, I plan to design in the open.
- As soon as I start I will open up a public GIT repo.
- I will commit my work along the way so you have access to the code.
- I will give everyone access to the URL i will be working with so that they can see the progress.
- I will be creating webcasts along the way to show my progress and show how I am going about designing in the browser.
- I will blog about my journey along the way.
By doing this I hope to show how one can approach designing in the browser. I don’t expect it the be all way of doing it, but my hope is that you could capture the principles and then make the workflow your own.
This should be fun! Stay tuned!
Create. Stop. Be Creative.
Some of the best advice I was given when I first showed interest in the web design industry was “Learn to design. Learn to develop.” Some in our industry would say that when I was given that advice, I was being directed to be a generalist. I disagree.
Why you might ask?
The reason I disagree is because I believe that in order for one to be a good web designer, they must know how to develop. In other words the advice I was given was essentially: “Learn to design for the web.”
Don’t get me wrong, I’m not saying that one has to be the best front end developer out there to be a good web designer. In fact, I work with designers that are far more gifted at design then I am, that know less about development then I do.
With that said I do believe that one needs to have at least some rudimentary knowledge of development to be a good web designer. I would even go as far as to say one must have at least some rudimentary knowledge to even be considered a web designer. This is because the very thing that separates a print designer attempting to design for the web, versus a web designer, is a knowledge of development.
Understanding Your Canvas
The reason I classify such knowledge as the defining mark of a web designer is because it is only when one has a knowledge of development, that they also have an understanding of the canvas that they are working on. It is vital for one to understand the canvas that they are working on. Why you might ask?
Take a painter for example. If they were going to paint on a canvas they would need to know what that canvas is made of, what paints work well with it, what techniques to use in relation to it, and more. If they didn’t have that knowledge, then they would have a difficult time in creating something on top of it. Their paint might not dry correctly. There might be inconsistencies in their brush strokes. There could be an endless amount of issues.
Just as a painter must understand their canvas, so must a web designer understand theirs. A web designer must understand what type of designs work better on the web then others. They must understand how the different components on the web are built. They must understand the dynamics and what causes designs to break on the web. Most importantly, they must understand their canvas as it is the key factor in deciding what workflows they use and how they approach designs. This is a massive decision and one that often either causes a project to be a success or a failure. Unfortunately we as web designers can have a tendency to miss the mark on this.
One Step Removed
In Ethan Marcotte’s book “Responsive Web Design” he talks about how we as web designers often approach our work by emulating a print workflow (3). The way we do this is we create a blank slate in our image editor of choice, define widths and heights, establish grids, and then begin to design. Once we have finished laying out all of our designs in our image editor, we send them to a front end developer. The front end developer then brings our designs into the browser.
After they are complete we begin to make lists of things that they did wrong and need to be corrected. Later when those are fixed, we open up our web browsers in our mobile devices and begin to see even more issues. We then send those back to the developer. Ultimately we end up in this endless ping pong battle of design versus development until we finally come to a satisfactory result.
As you can see this approach to web design is highly problematic and waists tons of time. We could easily try and blame the front end developers for not getting the designs pixel-perfect and for not cross browser testing, but in my opinion that is a cop out. The reason that it is a cop out is because the entire scenario could be different if we did not approach our work like a print job.
The reason we can’t approach our work like it is a print job is because while print design is rigid in nature, web design is fluid in nature. In fact web design is one of the few creative processes that allows a user to manipulate the canvas. As soon as one opens up a website in their browser window, they are able to change the size of the window, zoom in and zoom out, turn features on and off, and more. If that is the case, why are we creating our designs in an image editor and then calling our job done? I mean think about it. When we design inside our image editors, we are actually one step removed from our actual canvas: the browser window (Marcotte 3).
Own Your Canvas
When dealing with such a complex canvas, we must engage with it instead of insisting others do that for us. This brings me back to my point that when I was told “Learn to design. Learn to develop.” I was really just being told “Learn to design for the web.” This is because in order for us to not be one step removed from our actual canvas, we must engage with our actual canvas. In order to engage with our actual canvas, we must know how to develop.
I’m not saying that an image editor must be fully removed from our workflow. In fact I believe an image editor is an essential tool to a web designer. The problem occurs when we begin to treat that tool as our actual canvas. The browser window is our canvas.