The thing about Web Development is…

It is always changing. This is good but sometimes it can be a bit overwhelming. For example, ever since ES6 came out and the industry started moving more and more toward using the new specifications. I have started feeling like I don’t know javascript.

I have been writing in javascript for about five years now. The vast majority of it was in jQuery. Some of it has been with front end frameworks like Vue.js and Angular. I worked for about 6 months with meteor.js and node.js at my first development job. I can still drop some jQuery like no body’s business. I have built whole component libraries using jQuery, Scss, and HTML that are fully accessible and easy to implement. Yet when I see code that uses destructuring in complex ways, I am like ‘what the heck is that?’

It is javascript – the new javascript. There are quite a few parts that take some getting used to.

Arrow functions are another example. They are easy to understand and simple to implement. The syntax is simple and straight forward. But I could easily and quickly read and understand code that nested functions before that arrow came along. Now, I frequently see things that I have to take a moment to translate. Here is a fun, and simple example from the MDN docs:

setTimeout( () => {
console.log('I happen sooner');
setTimeout( () => {
// deeper code
console.log('I happen later');
}, 1);
}, 1);

This one is nice because it is fairly obvious what it does. But imagine if it wasn’t so obvious. I didn’t realize how much the word ‘function’ was serving as a visual queue for me until it started disappearing.

When you are learning, arrow functions are simple and straightforward. The syntax is a clear improvement for a simple function.


//New version
const cubeThis1 = (a) => a**3;

// 27

//old version
const cubeThis2 = function (a) {
return a**3;

// 27

When you are working with someone else’s code, they haven’t named their functions and variables so well, and the functions are not so simple, then you might find yourself stopping to translate. Every now and then I rewrite the code in comments or in my own notes with the explicit ‘function’ syntax to make sure I understand what is going on. The implicit ‘return’ of the arrow function throws me off sometimes.

Destructuring can also get very confusing very fast, especially if the writer of the code does not adhere to clean coding principles. The syntax feels backwards to me like I learned to write “The fox will run” and now I am being asked to write “Run the fox will.”

So I am practicing writing code far more than I used too, or than I previously felt was necessary. I have returned to some of the code kata’s and code challenges that I used as a new developer to try those same exercises in ES6. I sometimes refactor my code with more ES6 syntax to see if improvements can be made, and I always think about how my code communicates with other developers.

In spite of all this, I still frequently feel like I don’t know the language well, or rather that I know it less well than I did just a few years ago. It is the programming language that I am primarily writing in, and have plenty of experience with.

But then, in my career I have also had to learn PHP, Python, Ruby, mongo, SQL, HTML, CSS/SCSS, and a half dozen frameworks with their own syntax. And that list could go on because there are the API’s you work with, the libraries, the modules, the automation tools, the testing tools, and the browser dev tools which are perpetually getting new updates. Somehow, the ground is always shifting in web development.

It is so easy to feel like somehow you are back at square one, in spite of the 5 years or more that you have been climbing the web development mountain range. I feel that way. The other day I wrote some code for a small expanding panel with all the needed aria-attributes for screen reader friendliness, for another developer. I knocked it out in a matter of minutes, and then refactored it in another 10. That is when I found myself thinking – “Oh yeah. I do know how to write javascript.”

New syntaxes, and the complexity of incorporating new skills into your existing methods can feel awkward and fill you with doubt. This is a note for my future self the next time I am learning the big new thing that scrambles the syntaxes that I am comfortable with: You are not alone, and you don’t suck at this, so keep moving forward. 


How Web Developers Feel About Print Designers Venturing into ‘Web Stuff’


Save Us From the Print Designers

Imagine you are a design agency who has been making amazing, trendy print and marketing designs for years. You can knock out a well crafted logo, billboard, or brochure with an exquisite awareness of the market you are targeting, and the needs of your client in a matter of weeks. Your clients love your work and they return to you again and again for every pixel perfect brochure and poster.

Then one day they ask you to take charge of their new website design. Why not? You already understand digital branding and social media strategies, so why not take the plunge into this fertile uncharted territory?

Wait. Hold up. Please. I just need a few minutes of your time, for the sake of my sanity and the sanity of web developers everywhere.

Should you take that plunge? YES, of course you should, but not without the very clear awareness that web design is drastically different from anything you have ever done. You just left the world of static pixels, perfectly positioned letters, and layouts that always stay rigidly the same. You are walking into an interactive medium, a multi-device/screen width medium, and a multi-user medium.

You are no longer working in a space where you can assume you have one kind of end user, one size of canvas, or static images that simply hang out on a static screen. You may have to consider how the content of the site will change over time, how easy your design will be to manage and update, and you will have to know a thing or two about web accessibility.

You will also want to know if users actually interact with the the interactive elements of your site, and what to do if that amazing carousel you designed turns out to be a complete dud at actually marketing anything.

Still want to move ahead? Good. The web is a powerful medium and as a digital design firm, you should want to be a part of it. But it is incredibly important that you know what you are getting into. You might also want to know why you are getting that weird look from your developers when you surprise them with the fact that you don’t know what a hover state is. But maybe I can help with that.

So here is a non-exhaustive list of things you should know if you want to design for the web, and also a few things that will keep you from driving your developers crazy.

You are Designing Something that Other Humans will Interact with

This is so basic that it is hard to know where to start. You are no longer designing just to catch someone’s eye, make your audience feel a certain way, or to make a product or company seem more friendly. You are now designing elements that you want users to recognize as interactive, and then proceed to interact with those elements. So buttons need to look like something a user might want to tap on or press. Somehow you have to indicate to your users that this is an interactive element. The same goes for links.

There are plenty of well established design patterns for this. Menu icons, button styles, and even standardized link styles will help in conveying that information to your users, but you also need to give some feedback that an interaction is occurring or that it has been successful. This is where hover states, active states, and focus states come in. You will frustrate your users if you give them buttons and links that don’t respond with they interact with them.

Interactivity is about responding to user input. Learn about the different states that you might add to a button, and don’t go crazy designing these states. Less is more when it comes to button and link effects, especially if you have quite a few of these on your website.

Content and navigation have to play well together

So now that you have realized that something needs to happen when your user presses that menu button, have you thought about content?

Let me guess. The client is providing their own content? That’s great, but I bet you are designing their navigation, and that navigation needs to have some relationship to the content… right?

So you are going to spend some time working with your client’s proposed site map. This is where your digital marketing prowess will come in handy, because you are going to tell them that submenus inside of submenus inside of submenus might not be a great idea, or that top level menu items probably need to be short and sweet and definitely under three words long.

You are going to realize when you start mocking up these menus based off of the site map, that their site map is implying some things that might not work so well. So have an idea of how you want to guide them.

If you think simpler menus are better for their design, then that main navigation might need to be slimmed down, and remember that the menu is generally for the end user not your client. It may look cool to have images, videos, and multiple columns of menu items in your dropdown menus but that may not actually be the best design choice for the site. Think about what your end users are actually going to look at and click on.

Welcome to the Mobile Web

Speaking of which, now is a good time to think about how that giant menu is going to work on mobile devices if you haven’t already. You can start with mobile rather than desktop, some designers really like to start with mobile, but you don’t have to. Just remember that on mobile most of those ‘click’s’ will turn into a ‘touch’ or ‘tap.’ ‘Hover’ isn’t a thing, and ‘swipe’ decidedly is.

Design with touch interactions in mind. All of those mobile menu icons and buttons are big enough for an adult human finger to touch them without touching other links or buttons at the same time, right?

You are also carefully designing with super small screen real estate in mind for all of those tiny iPhone 5 screens that are still out there.

I’m sure that you have already done a little bit of market research and figured out the range of devices that you would like your design to fare well on, and maybe even negotiated a little with your client on the edge of those ranges.

Hopefully, you have also talked to your developers about what they think is reasonable to support. Your clients will want to support everything imaginable. You will discover a growing expense that directly correlates with the age of the devices and browsers that you try and support. Supporting older devices and browsers are much more development intensive.

Sooner or later, you will have a client who owns a very decrepit Samsung tablet from back when no one knew Samsung even made a tablet, and they are going to want to know if their new fancy website is going to look good in landscape mode on that 8+ year old tablet that their kids are still using. The answer will be ‘no’ but you will need to find a diplomatic way to deal with the situation and similar ones that arise.

Did I mention landscape mode earlier? You will need designers and developers that have a good grasp of responsive website design and development because you do not want to try and design for every possible range of device width and device orientation out there. That is to say that it is much better to have a website that reorganizes itself properly for different screen widths rather than worrying about hundreds or even thousands of different possible canvas sizes and orientations.

Three designs should cover most of your needs: i.e. a small mobile layout for small devices in portrait mode, a medium layout for tablet devices, and a large layout for desktop. There are plenty of well established breakpoints out there for responsive web design and development. Use those if possible, and try not to veer into making too many unique ones of your own. Every new design variation equals more development time, which will add up to a much larger expense. If your client is footing the bill for all of that development time you will need to keep that in mind and err on the side of frugality where possible.

Web layouts are dynamic

I mentioned it above, but it is worth mentioning again, you cannot control or design for every possible device size and orientation. There are just too many of them, and guess what? Each of those devices has multiple browsers that run on them that might also impact how your design renders. So you need to develop an understanding of how HTML and styling can respond to different device sizes and orientations.

For example: text wraps. That’s why putting five words in a menu button is a bad idea. it’s going to wrap on mobile, and suddenly one mobile button is going to be much bigger than all the others. The same way you have limited usable design space on a business card, you have limited space in a menu item, and this is especially important when considering if your clients might want to add more menu items in the future.

Text wrapping is one of those very necessary parts of the web that endlessly baffles print designers and clients who are accustomed to the pixel perfect arrangement of a well crafted brochure. Text has to wrap. Do not try to perfectly design where a line of text breaks across every screen width.

Millions of dollars, possibly more, is wasted every year by print designers and not-so-web-savvy clients trying to get their developers to write custom code and styling to keep lines of text from breaking in inconvenient places. This will come up often. So remember, you are not designing a poster or a billboard.

Text is going to wrap based upon the space that it has to work with, and a skilled developer’s job is to make sure that the layout responds correctly.

Did you notice how all that extra text didn’t leak out of the button, it didn’t disappear or get cut off, and it didn’t end up jumping on top of anything else? Did you notice how that callout box managed to contain all of your extra text and expand as the paragraph got taller and narrower on different screens? Your developer did that. Your welcome.

Background images — it is a remarkably similar problem to text wrapping. When aspect ratios change, which they will for different screen width, how the background image covers the area will change. That means a focal area or area of interest in an image might shift or even get cut off.

Honestly, I’ve had to explain it to more than a few print designers. Why does this image position differently in a panoramic space — lets say 300px height and 1600px width, than it does in a mobile space that is 200px by 400px… Because it does.

Developers have a little bit of leeway in tweaking this but frequently we end up with clients that want the focus point on one image in a standardized layout to be on the left, but on another page it will be on the right, and can we shift that when we get to small screens? Can we customize it across all 50+ pages of our website for each layout (mobile/tablet/desktop)? This can get hairy and time consuming very quickly. So pick good images for the space that they are designed for and maintain some consistency across similarly designed pages.

Also, you should consider just having different images for mobile that are already optimized for the space they are in. It is often substantially easier to just give the developer the correctly sized and cropped image for that small screen than trying to get them to spend hours tweaking how a large image responds to a smaller canvas.

Website content changes

If I had a nickel for every time I worked with a designer who designed a page layout without considering how it would look if the content was entirely changed, I would have quite a few nickels.

So what happens to that carefully designed callout box if it suddenly had a three line heading instead of a three word heading? What would happen if your client put an image there, or a bulleted list? Sometimes your custom layout may need some content restrictions, and you may need to work with your developer to figure out the best way to make that happen. You will also need to communicate these issues with your client who I promise will imagine that they can add whatever they like to whatever space that you have designed for them.

Digital Content and Services should be adaptable to a wide range of users

This is the hard part but also the best part of working on the web.

Your website shouldn’t be a brick!

What do I mean? I mean back when most content was delivered via printed pages in a book or newspaper, you could safely assume that your users were going to navigate with their eyes and fingers right? Content came in a very static form, like a brick. It didn’t change and you could reasonably expect your users to figure out how to work with what you were presenting them. If they couldn’t work with what you were giving them then they just got left out.

Likewise, on the web today, many designers and developers assume that their users will navigate their website with a mouse, well functioning eyesight, perfect lighting conditions, and a never-dimmed backlit screen.

Don’t assume anything is consistent about your users, and more importantly remember that digital content is not brick-like. Digital content is infinitely adaptable and that is why you should be trying to serve the widest range of users that you possibly can. That means supporting users that want to navigate via mouse, keyboard, touch, screen reader, and even voice interfaces.

Digital content can easily be resized, recolored, shifted, relocated, downloaded, repurposed, or even read out-loud by end users devices. This can be challenging to stay aware of and work with, but it is also what makes the web such an incredible medium to be a part of.

You can get started with accessibility by just being aware of a few important things:

Contrast matters — find a good contrast checker and aim for 4.5:1 or higher for all of your standard text content. Larger text (24px and larger) can use a 3:1 contrast ratio, and be be aware of how readable text is when sitting on top of a background image.

Don’t disable zoom — ever.

Avoid autoplaying content.

Leave your focus outlines on — keyboard users use these for navigation. You can improve the design of them if you like, but please don’t get rid of them.

Use HTML and styling instead of text images where ever and whenever possible.

Respect heading order — document structure should be logical and not based on styling preferences.

Test your forms and workflows with a screen reader! Trust me. You have one built into that Mac you are using for your design work. I promise you have one. “Command F5” — try it out.

There is much more to accessibility but that will get you started.

Check out this article on how to get involved in global accessibility awareness day:

A few other things that you can say that will make your developer laugh (or groan) at you

“Did you know that fonts render slightly differently across different browsers?”

Dev: Yes. Its actually a much bigger problem across operating systems.

“Why can’t we just let the responsive HTML to do it’s thing?”

Dev: You know HTML doesn’t magically become responsive on its own? Right?

“How come this giant square image doesn’t look right in this narrow space designed for a panoramic image?”

Dev: We gave you image dimensions, could you possibly use those?

“Why does this image load so slowly? It’s only 10mb.”

Dev: That image file size is 100 times bigger than it needs to be.

“We need images appropriately sized for the web? Can you optimize my 200+ images for me and then re-upload them to our site?”

Dev: Let me google ‘3rd party image optimization’ for you.

“Embedded 3rd party content doesn’t need to be accessible… does it?”

Dev: “It does in fact need to be accessible.”

“I’m working on my meta-keywords.”

Dev: Your SEO techniques are about 10 years out of date.

“Can you turn off that weird blue line around my buttons?”

Dev: That’s the focus state, and it is essential for keyboard navigation.

“What is a hover state? / What’s a style guide? / What’s a wire frame?”

Dev: What kind of design did you say you had experience in?

“Why can’t we customize where the text in this callout breaks across every page — all 50 of them, for all devices.”

Dev: If you went live without these perfectly customized text breaks, would you have a single website visitor ever notice or care? Seriously, if the answer is ‘no’ you might not want to spend developer time on this.

“We need motion on our site, can you add (insert random effect here).”

Dev: Motion, like any design element should be used with purpose and moderation. Please don’t just add motion because you think it will make your site more “modern.” Your site visitors will be impressed with well designed animations and effects that work cohesively with your site design and serve its overall strategy. This is the age of the smart phone, I promise no one is impressed with your perpetually moving ads and gratuitous parallax effects.

“We would like this to autoplay.”

Dev: I promise you do not have users that like autoplaying content! You don’t!

In conclusion

Obviously, there are more things to learn, but this should get you moving in the right direction and hopefully reduce the headache of the developers that end up working with you.

I know the web is a very familiar place for you, but there is a good chance that interactive and accessible design is very new territory. That doesn’t mean you shouldn’t be here. There is always room for better design on the web.

Do you remember what it was like get “access” to the web when you were young, and when the web was much younger? Remember when you used the word “access” to complain when you couldn’t load a page, download a video, or “access” your email? There are still users struggling to get access to many online sites and services out there and they would love to interact with your carefully crafted website. Keep those people in mind and build/design for the widest range of users that you can.


Activating Interactive Element with Keyboard;

From Mozilla Developers Network

The method simulates a mouse click on an element.

When click() is used with supported elements (such as an <a style="text-decoration: none; color: #3f87a6; margin: 0; padding: 0; border: 0;" title="The HTML element is used to create interactive controls for web-based forms in order to accept data from the user.” href=””&gt;), it fires the element’s click event. This event then bubbles up to elements higher in the document tree (or event chain) and fires their click events.

The most important thing for you to remember when trying to make your site’s interactions work with a keyboard is that when navigating with a keyboard, “hover” is not a thing. When keyboard users want to interact with an element they expect to be able to hit enter/return to activate an element. Luckily, the keyboard return event syncs with the mouse “click” event.

Hence, if you know how to make something activate on a mouse click, then you should already be able to make it work with a keyboard. However, unlike the mouse where user navigation is more implicit, you will need to think about how the user navigates to the “clickable” element and whether or not they can visually see that they have arrived at the “clickable” element.

This is where visible focus states become especially important and I have an entire article dedicated to this topic.

Navigation and Interaction

This is where the keyboard interaction can get a little bit dicey. You may have carefully and cautiously made every interactive element on your site activate via keyboard, but this will not matter if the keyboard user cannot navigate to those elements, or are not able to see that they are on the interactive element when they want to activate it.

With a mouse, we don’t have to worry as much about how that navigation occurs. We can safely assume that the mouse user has some kind of arrow or cursor with which to see where they are on the site and to indicate which elements they are interacting with. In addition, most sites use changes on hover to give further visual cues to the mouse user that they are on an interactive element.

Unfortunately, it is not uncommon for some interactive elements to be completely in-accessible to keyboard users because they cannot navigate to them.

It is helpful to think through how your keyboard users navigate to, and interact with an element, in order to fully test whether or not your interactive elements are actually keyboard accessible.

Steps for keyboard interaction

For the sake of this example, we will pretend that we have an accordion element – a series of collapsible elements that expand or collapse by clicking on a bar or button.

Imagine that the keyboard user wants to navigate to and open the first item of an accordion element in order to view the content inside of it.

  1. Step one – The user navigates to the element using their keyboard.
    • This is typically done by clicking on the “tab” key.
    • The tab key will immediately move keyboard focus to the next focusable element on the page.
    • The user will see the visible focus outline on that element and will continue clicking “tab” until they successfully arrive at the element that they want to access.
  2. Step two – The user arrives at the element they want to interact with
    • The user knows they are on the correct place because the element with keyboard focus is clearly visible – this is typically shown via a blue outline or dotted line.
  3. Step three – The user clicks “enter/return” to activate the element.
    • When a button element is used the user should also be able to use the spacebar key to activate it.
  4. Step four – The element activates.
    • The accordion panel expands and the user should be able to navigate into the new expanded element if there are focusable items inside of it, or if they are using a screen reader.

Step 4 isn’t really a step – it is the outcome, but it is important to think about what we expect the user to be able to do once that element has been activated. Frequently, the element being activated is a menu or navigation list with links to additional content.

Activating the element, is often only part of the process. It is also important to verify that the user can interact in the expected way with whatever has changed on the page. In this case, it was a an accordion panel that expands. If that panel contained interactive content then it would also be important for the keyboard user to be able to navigate into the new panel and interact with the content inside of it.

A Process for Verifying Keyboard Usability of an Element

Here is a basic list of items that you can check to see if your keyboard interaction is working well. Please note: I am not listing techniques for accomplishing these items here as that would be a much longer article.

Before element activation

  • The keyboard user can navigate to the element.
  • The keyboard user can see that the element that they want to interact with has focus.
  • The keyboard user can activate the element via a click of “enter/return” on the keyboard or with a spacebar click when a button element is used.

After element activation

  • The keyboard user can immediately navigate into the activated element.
    • This is especially important for pop-up windows and drop down panels.
    • For example, the user should not have to navigate through the remainder of the page to get to a popup window or panel that just activated.
    • In the case of a pop-up window/modal that is sitting in front of the other content, you should immediately move the keyboard focus to the new element.
  • The keyboard user can interact with the content inside of the activated element if there is interactive content. A screen reader should also be able to be aware of and read any content that has been displayed.
  • The keyboard user can close or deactivate the content.
    • Deactivating the interactive elements is especially important when those elements block other content on the page. This is a common issue for dropdown menus and popup/modal content.
    • “Re-clicking” the focused interactive element that is open or active, is generally expected to close it again.
    • Connecting a “close” or “deactivating” event to the “Escape” key is also a common practice.
  • The keyboard user can navigate away from the deactivated element.
  • In cases where the activated element is overlaying or blocking other content, the activated element should close or deactivate if the user navigates away from it.

Consider User Expectations and Unplanned Behavior

Generally, the keyboard users expect to be able to re-click an element in order to deactivate it. However, it is not uncommon for developers to build in other shortcuts like closing an item on an “Escape” key press. It is a good practice to have a backup way to close a panel and “Escape” is the most common, however do not assume that your user knows that the backup or shortcut method is there. If your users expect to be able to re-click an element to deactivate it, and you do not have a good reason to not have that functionality, then you should probably build that in.

Also, think about what happens if the user fails to close the element.

Suppose you have a large video popup that takes over most of the screen. You would not want the user navigating behind this element, and trying to interact with elements behind the popup that are not visible when the video panel is open. In this case, and in cases where an activated element covers part or all of the content underneath, you should force the content to close or deactivate when the user navigates away from it. That way, content that is blocked does not continue to be obscured once the user is no longer interacting with the overlaying element.







Web Accessibility – Where to Start

Many businesses, when faced with the prospect of making their websites accessible do not know where to start. This post is intended to help with that.

The easiest place to start for most web site designers and administrators is with color contrast. Color contrast refers to the level of contrast the text on your site should have to its background.

There are two primary levels that you should be aware of the 3:1 contrast level for large text, and 4.5:1 contrast for small text. Large text is text that is 24 pixels in height or larger.

A common error is to presume that the 3:1 ratio is good enough for all text across your site. Unfortunately, it is not. Because smaller text is more challenging to read it requires a higher level of contrast to be legible. Small text and this generally includes your standard body text, needs to have a 4.5:1 contrast ratio. In addition, you should never use text, even fine print text on your site that is smaller than 10 pixels.

If you are in doubt whether or not your text should have the 3:1 or 4.5:1 ratio, err on the side of caution and just use the 4.5:1 ratio.

Determining Contrast

There are a number of tools that will check your contrast levels for you. Developers typically use a tool like Webaim’s wave checker to determine the contrast ratios on their site. This comes in a convenient chrome extension. In addition, you can use Webaim’s color contrast checking tool to try out individual colors and backgrounds.

Why is Text Contrast Important?

For a number of years it became somewhat fashionable in website designs to use very faint text, particularly in form fields and in footers. This low contrast text causes major problems for site users who have low visibility. You do want your site visitors to be able to read your content, right? That is why you put the content on your website, right? So give it enough contrast to be legible to the widest range of users possible.

The Design Dilemma

I really like creating awesome website designs. I am consistently amazed at what css can do now that it couldn’t do 15 years ago. When I made a website in high school (circa 1998), I spent hours putting little bevels and drop shadows on my buttons. That was when CSS was this fancy extra thing that seemed like way too much trouble to bother with. Now a few extra lines of code and gradients, drop shadows, and even circular buttons are easily done with zero photo-shopping involved. It is really amazing, but I also love the process of figuring out the logic of working out the back-end.

On my final project I was most proud of creating my own search engine for our app that searched our database by geocode (latitude and longitude) and returned all the results within a ten mile radius. Of course I didn’t create the actual function that calculated area of a circle from a specific set of coordinates plus a radius, and then looked for lat/longitude coordinates that fell within that range, but I know I could have. I took two semester of geology and the physical geology class involved a lot of work with maps and lat/longitude coordinates plus geometry has been one of my passions since I was a kid… so yeah I could figure a range of latitude and longitude coordinates that fit within the area of a circle on a map.

I love that stuff. I love figuring out how to create sophisticated search queries and return only the desired results. I love that exact sort of problem. My dilemma is what to focus on.

Visual design is great, I already have reasonably good skills and experience doing it, and I have already had one job that I loved, doing exactly that. The downside: the difference between good designs and great designs is often just subtlety. Take a look at one of your favorite websites -WordPress for example. It looks like a pretty simple design. But check out all the subtle effects that someone had to put there. Subtle borders on each box, a very subtle gradient on the “publish” button, a soft-drop shadow below the top bar, the hover effects that occur a little slower than most, the single well functioning drop-down menu. It’s all stuff I could do, but the hours and hours of tweaking and subtle changes I would have to do to get it just right, well that’s the trouble.

I was raised in a family of artists and I have a great eye for creating graphics and taking good photos, but I am constantly in awe of what I see on just basic website designs these days. It’s gotten so zen. Gradients so subtle you wouldn’t notice if you weren’t looking, show up as hover effects in my gmail account. Ever-so-slightly rounded corners, here, there, everywhere. Css animations controlled by milliseconds, because even though most people aren’t going to consciously notice, we do notice subconsciously. That sense of a site being just “thrown-together” by some internet-marketer or spammer versus the professionalism of google, wordpress, and facebook is all in the subtlety.

So maybe I miss the days when creating my own tiling brightly colored backgrounds for my geocities-site impressed everyone (mwa ha ha). It’s a little of that, but there is also the very real understanding for me that modern webdesign is about mastering subtlety, and I think I would rather master programming logic, and solve those interesting back-end challenges that require a thorough logical thought process, a little bit of pseudocode, and a few trips to google to figure out.

It’s a big dilemma for me. Geometry and o-chem were my favorite subjects in school because they required both logic skills, and the ability to understand problems in a visual way. I’m back to feeling like I have to pick one. I just don’t quite understand why a 3px border-radius makes a button look so much more professional than leaving it with regular corners. There’s got to be some logic there but what is it, and how do I anticipate it? I feel like I’m just copying. It looked nice when wordpress did it… so why not?

On the other hand, the stuff I have read about user interface design and user experience is the most fascinating and thought provoking material I have found on the internet. The potential for changing how people think, learn, and interact is kind of huge, and it all comes down to thinking about, and understanding the user experience -which brings in an understanding of learning, of human psychology, and of intuition. Dismissing UX/UI as an area of focus is like dismissing the open source movement in the 90’s as being a viable movement (lol – Linux, rails, and github have been my life-blood for the last 3-months).

So yesterday, I started re-working the design and user interface of my final project, today I started getting into the nitty gritty of how search engines work, tomorrow more css-sass, a few days ago I was learning regular expressions, and this week I want to add javascript functionality to a periodic table app I’ve been working on.

It’s fun, it’s fascinating, it’s invigorating, and the focus is long-gone.

Tonight’s The Night

Today is Career Day, which basically means we are demo-ing our final projects tonight. I’ve got that nervous/excitement that goes along with giving public presentations. Our presentation has been refined, but there are still so many things I would like to fix on our app. There are a few bugs that just showed up, our calendar is awesome and working, but the edit feature still has a few hiccups. I got our geocoder/google maps search function to work. So no more simple name search… we have a full blown geocoded data base search! 

I made a screen cast to demo the app in our presentation. The user authentication works great! But there is an odd bug on one of the account screens… oh devise, how frustrating you can be. That being said we have a user authentication system we didn’t have to build ourselves which is incredible. We just refreshed the layout and it looks a thousand times better, but there are still so many things I would like to add, adjust, and fix.

I was told yesterday not to bug-check anything else… no more fixing. If the website is up and working… let it be. So I am. No more tweaking, no more code… just letting it happen. We will be at capital factory tonight in downtown austin. It’s going to be exciting. 

My Awesome/Frustrating week

I have had and done some really awesome things this past week. I’ve also had massive frustrations. There was the struggle to figure out how to get user authentication to work correctly in my app. then there was implementing a google maps search, which is super easy if you are working with a single html page… not so much when you are working with a whole app. I tried three different methods including writing all the code myself. Ultimately, I went with the gmaps4rails gem which was not easy (very bad documentation), but it turned out to make more sense then rewriting everything myself.

I wrote a simple search engine that allows the user the type into a search box, this searches our therapist database, looks at the location attribute, and sees if any of the words match. Then it passes in the geo-coded locations to google maps and create markers on the map associated with each therapist returned.

It works! However, I need to fix it to search for geocodes (already in the database), and return actually nearby therapists. Right now a search for ‘austin’ will return any location with the word “austin” in it, even if it is a street address in Washington State. That won’t work so well for finding therapists in Austin, TX. So even though I am quite proud of having a working search engine that I coded myself, I think I may have to mostly scrap it.

Maybe I will set up options to refine the results: “Did you mean Austin Tx or Austin, ST?”

The other big problem was that after getting our user authentication set up with Devise, it still would not allow us to save all of a user or therapists attributes to the database when we used the new user/therapist sign-up and account-update pages.

It turns out, there was an extra configuration step that was needed specifically for those forms. Anyhow, got it working. Users can now add to our therapist and user databases, which then works with my awesome search function.

Awesome! So today I am tackling the Heroku deployment. The Beta version of Therapy Lane is coming soon!