I’ve been heavily working with jQueryMX for my latest web UI project, a JavaScript MVC chosen by my client. I’ve been wondering if there are alternative approaches. MVC wasn’t invented for UI after all, and quite often I find it confusing whether a certain piece of code should go in the model, view or controller.
Fortunately I ran across a few interesting alternatives lately and decided to share them. If you’re going to do some heavyweight JavaScript lifting for your next web app, and you feel experimental, you might try some of these JS frameworks out.
MVVM = Model View View-Model
This pattern was made for event driven UIs, thus making it perfect for web apps. Instead of writing loads of GUI code, it allows binding elements from the view to the model. Thus when one changes, so may the other.
Knockout.js uses this pattern. As you can see in their example code below, the HTML defines not only the layout, but also the events on each UI element and what it should trigger. The backend JS code binds to it and says what to do:
knockout.js example code
On first look I was shocked. Everything I know about JS so far, especially due to jQuery, was to keep Kosher and separate behavior from the view, i.e. the JS from the HTML. This framework puts at least part of the behavior in the HTML which is a big no no regularly.
On second look, what they did with a few lines of code would take plenty more if I had to write this otherwise. It also allows describing the UX in the HTML first and writing the backend code later, a rather cool way of development for a UX driven developer like me.
The real test would be to actually use it for a big ass web app and see what happens when the shit hits the fan. Does it work well with plugins and UI frameworks? Does it tango with AJAX? Is it easy to maintain?
Bottom line – looks really promising, needs to prove itself in big complicated web apps.
So, what is it all about? Elements are basic UI elements such as text boxes and buttons. Blocks are either groups of elements or other blocks, such as search (input + button), or site header (logo + nav + search).
The idea is that blocks are independent and can be glued anywhere in your project, thus allowing code reuse. In case you want them to be a little different somewhere in your app, a modifier is used. It could be implemented as an extra CSS class that’s appended to the HTML tag.
There’s logic to their approach. Recently I’ve separated myself UI elements in a web app to widgets and components, which correspond exactly to their separation between blocks and elements. However, is it worth it to throw away what we’ve learned from MVC and organize our code only by visual means?
Also, there’s too much custom stuff involved with BEM. They use their own language called BEMHTML which is based on XJST, their own JavaScript templating engine. Other frameworks have started as in-house frameworks, so maybe I’m being too suspicious. Still, I don’t see enough organized documentation in English, and they barely discuss the JavaScript behavioral part of it all which makes me reluctant to even try it out.
Bottom line – nice to see a different and logical approach, needs way more time to mature.
What to do? I may try knockout.js to prototype my next project and see how it handles. If it works well I’ll go with it, otherwise I’ll probably revert to the web’s most popular framework – backbone.js or stick with jQueryMX and JavaScriptMVC though it seems less popular.
Like the rest of the world I’ve caught the Draw Something madness. This is the best and funnest app ever. Its developer is a genius.
Playing it for hours and hours in the last week I realized not everyone has figured out how to play it well. So just in case, here are 8 tips how to improve your Draw Something skills, get lots of coins, and have more fun sketching.
Set the context. Don’t just draw an abstract shape and leave it, draw its surroundings as well. Is it handheld? Sketch a hand holding it. Is it on the ground? Draw it on the ground under a sunny sky. Is it at sea? Paint the sea with some waves or it could be mistaken for a sky.
Think associatively. Add anything that comes to mind when thinking about the sketch word. For example, if you get the word “Brazil” you can pinpoint Brazil on a world map, sketch the Brazilian flag, a carnival showgirl, a soccer ball, the beach, etc. The more, the merrier,
Use the right colors. The sky should be blue, the ground yellow/brown/green, lips should be red. If you don’t have an expanded color set yet, use a substitute color and add text to tell your friend which color it should actually be.
Stick to caricature stereotypes. Need to paint Lady Gaga? Do her big sunglasses and famous hair bow. Beyonce must be sketched with a bootylicious body. Give pirates and vikings a mean looking face and doctors and children big smiles. Mustaches should be hairy and giraffes should be tall.
Do several sketches via the trash. Trashing your sketch is good in case you messed up, but you can also use it to do several sketches of the same thing. One sketch of popcorn could be someone holding a bucket of popcorn in the cinema. A second sketch could show a whole corn, one grain, a microwave, and then a popcorn.
Use number for different states. To sketch the word bounce, mark 1 a ball about to drop on the ground, 2 as it goes on the way up, 3 when it drops again, 4 when it goes up again. That’s definitely clearer than just showing a ball coming towards the ground.
Use arrows and circles.You can use arrows to show movement, actions, or point to a specific part in your painting. Circling can have a similar effect by emphasizing the most important part in your sketch.
Give textual clues if you must. Only do it as a last resort, and choose them wisely to keep things fun. Personally I delete people who give away the word itself, but some cute clues can’t hurt. E.g., when sketching the word “twist” aside from showing a stickman twisting away I added the words “come on let’s _____ again”.
I have just spent several hours debugging why Arama’s new WordPress website stopped working after I moved the WP installation to a different directory.
Conclusions:
Check the .htaccess file and change it accordingly.
The Israeli Ministry of Industry Trade and Labor launched a new marketing campaign to get Israeli businesses online. It’s a joint operation together with Google, Visa and Israel Post, amongst others. This is a big campaign with Youtube video ads and even public adverts in bus stations:
Their offer sounds quite good – free website + domain for one year. One registers, chooses a website template out of a dozen or two, and gets going.
When I first saw this, I freaked! Am I going to lose business due to this big campaign with free offers? Is my business, which builds websites for SMBs, going to go bankrupt!?
Luckily, the answer is no. The technology behind this project is based on Webydo, a content management system built on ASP.NET. They’ve got some major problems:
Usability sucks. I found that using the Webydo system to setup a demo site was extremely annoying. There are good intentions there. It’s a WYSIWYG, but not a very well thought out one. Heck, I wasn’t even able to publish my website since there was no publish button in sight!
Closed system. If you’d like to have a different design or add new features, you’re f***ed. You’ll have to wait until Webydo develop it, if at all.
Marketing ploy. You got a free site and domain. That’s cool. For one year. When time’s up you’ll have to pay Webydo for their services on a monthly basis. Data cannot be exported properly since their system only allows exporting the entire site as HTML files. Yuck.
WordPress, the platform I gladly support and develop with, is the exact opposite:
Great usability. Plenty of effort has been made through the years to make WP more comfortable to use. By far, its the easiest to use CMS I’ve seen out there and it keeps improving.
Open system. WP is open source, so you can get down to the last line of code if you need to. Plus you can install any themes and plugins or develop new ones if you’d like. If you’re tired of WP you can export all the data in a standard XML.
It’s free. Unlike companies who develop their own custom CMS, I don’t charge anything for the system, only for my services. Monthly costs for WP are only for hosting and nothing else.
I don’t understand why the ITL decided to go with a paid and constricting solution. Actually, I do. This is typical of Israel. As usual there’s money involved, lobbyists, connections, and I’ll scratch your back you’ll scratch mine mentality. Tomer Cohen’s post throws plenty of well deserved light on that darkness (translated).
If only the Israeli authorities had been more open, such a campaign would’ve used only open source technologies. Heck, maybe even the government would’ve thrown some money at developing them, maybe to translate more plugins and themes to Hebrew. It’s all there and ready. Even if it wouldn’t have been WordPress they could have gone for another open source solution like Joomla or Drupal. Damn capitalists.
My guess is plenty of SMBs will take up this offer for a free website. After a while, they’ll realize that they’re stuck with a system they can’t change and will soon have to pay plenty of shekels for. Israelis hate to be suckers, so by that point they’ll get angry, leave and look for a better solution.
Hello! My name is Ido and I make fantastic websites for SMBs
Lately I’ve been building more websites for small to medium businesses, and I’ve come to a realization. There is something wrong in the process by which most SMB websites are being built these days.
Usually the process works as follows. You want a website to show off who you are and what your business is about. You might have some idea what the site should look like and which cool features you’d like to copy from the competition. Then you give a call to your designer.
The designer meets you over a cup of Joe. She tries to realize what you want and takes it at face value. Then she’ll go home, make the magic happen, and come back with some fresh sketches. You’ll approve one of them, and voila, the entire website gets designed. Then it gets to the developer.
The developer usually knows one thing – how to develop. Some design corrections may happen following the developer’s feedback, but hopefully he’ll get the site done the way it was designed.
Then it’s back to you with the final result. Usually some minor corrections happen at this stage, then the site goes live.
What’s wrong here? Some crucial pieces of the puzzle are missing. You may not realize it, but the site is kaput, even if it looks like a million bucks and works flawlessly across all browsers.
Who is your site about? It’s about you, right? Let’s think about it. The designer and developer want you to be pleased, so they do exactly as you say. The problem is that you think the website is about your business. You’d like the site to make your business look real cool and that’s all. But you’re wrong.
Your website should be about your clients. They are the ones who are going to visit your website. Isn’t the whole point to get them to do something while they’re there? Maybe to fill a contact form, sign up to the mailing list, buy a product, etc. If all users get to the site, say “oh neat” and then leave, they’ll forget about you in 10 seconds. Would that make you happy? Probably not.
This raises important questions. Who are your clients? Maybe there are several client profiles rather than one? What do they want when they visit your website? Ultimately, what would you like them to do when they visit your website? The entire website should be built around that.
Having an about page is not enough. Writing some copy is not enough. The more users have to think to understand how you can help them get what they want, the higher of a chance they’ll use the most common feature in the web – the browser’s back button. In the words of Steven Krug, don’t make them think, give them what they want on a silver platter.
Unfortunately the client, the designer, and developer are oblivious to this. There is no fourth person in there to help them with the site strategy and structure. So we get plenty of ‘About Us’ websites while it should be ‘About Them’, about the clients. Because if they don’t easily get what they want from your site, they’ll go somewhere else and you’ll end up losing money.
In fact, looks like I’m also suffering from this problem. My own website is built all around me. My work, my abilities, my blog. In fact, it should be built around my clients – either startups who are looking for a frontend developer, or SMBs who’d like a website. I’m in the process of reassessing my business, so expect changes soon.
In the meantime, check yourself before you wreck yourself. Is your website about your clients? If you’re a designer or web developer, are the websites you’re making for your client’s clients?
After changing some copy for this website I asked friends for some feedback. One of them claimed that for a jQuery & CSS expert my site doesn’t have much pizzazz. I agreed.
Usually I’m not a fan of trendy web pizzazz, I’m a bigger fan of simplicity and usability. Nonetheless, I understand the need for the shoemaker to have awesome shoes.
So, I decided to increase the ‘wow’ factor a little in my site, and enhance some usability along the way. Here’s what I did.
Sticky top menu
If you scroll down a little, the menu will stick to the top with a nice fade out – fade in effect. This great tutorial helped. The advantage is that the contact me link is always visible, possibly increasing chances for new offers. Not sure if it’s annoying or helpful, so let me know.
Notice that the blog navbar item is in a different color and not linkable. That’s because you’re on the blog page. It’s supposed to help with orientation on the web page, to increase the feeling that you know where you are.
Dynamic content loading
Recently I launched a nifty WordPress based website with dynamic content loading + effects. I thought, hell, I could do the same for idosius.com!
After struggling with it for several hours, I realized that it wouldn’t work with my theme. The content area would constantly increase and decrease in size, something that looks quite annoying.
Dynamic content loading is definitely cool, but you need the right design for it.
The message was waiting in my (physical) mailbox – I have a package at the post office. Weird, I thought, I haven’t ordered any books lately. Going to the post office today and waiting in line, I got this cute package from the Google Engage program:
It includes the mandatory opening letter, a free wireless mouse, and a bunch of vouchers for free AdWords funds to give away to my clients. Cool, I thought, I could hand out these out in my next meeting and make some customers happy.
Unfortunately, a closer look revealed a major fault. The vouchers are only valid until 31/12/11:
Today is 29/12/11. Talk about the holiday shopping rush. Am I supposed to give emergency phone calls to my clients and tell them they have exactly 2 more days to use these vouchers? Good thing I didn’t hand these out to the meeting I have on 1/1/12!
I don’t know if the validity date printed on the vouchers is incorrect, or they sent out the wrong vouchers, or what. There’s even no email address or any contact details in the package, so I can’t even ask anyone what’s wrong.
I love Google, but they really f***ed up this time.
Update – 1/1/12 – After contacting Google Engage’s marketing manager, Alon Chen, via Linkedin, I got a quick reply from one of the Google Engage representatives that my vouchers will be automatically extended until 31/12/2012. They claim it took a while for the vouchers to arrive since my snail mail address in my Engage profile was incorrect. Checking it I noticed there was no address at all, so it’s nice they made extra effort to find my correct address and send the package to me.
Clients notice bugs. That’s a given, and a great thing. I would rather that they find bugs than their clients which results in more humiliation and frustration.
The only problem is that they don’t know how to report them to me in a clear manner. Too often they use a single line of text with vague terms. It makes perfect sense to them because they know the context. However, it fails to help me since I am out of that context.
Bugs by Mike Costelloe
Being a former QA engineer and now a web developer, here are some tips straight from the horses mouth how to report bugs to web developers. Reporting clear bugs will help developers understand the bug, fix it, and thus will decrease work time, emails, and turnarounds.
Take a full screenshot of the browser. Found a bug? Take a complete screenshot of it immediately. Don’t crop or resize it, send it in full size. It helps the developer notice subtle things that may cause the bug. Mark the issue in a red circle if it helps in any kind of way. Save it as JPEG so that the file size stays decent.
Choose a good title for the bug. Not too long, not too short, that includes the essence of the bug. E.g. “Video loads on the left instead of center in IE 7″. If the bug scenario is complicated, use the magic words “in a certain scenario” and see the next tip please.
Write reproduction steps. Take a moment to notice exactly how the bug happened, and break it down into clear 1,2,3 steps. Here’s an example:
Surfed to www.bugsite.com
Clicked the video
It opened on the left instead of the center of the screen
Note the environment in which the bug reproduced. Talking about:
Browser + version – IE 6/7/8/9, Firefox, Chrome, Safari, Opera, etc.
Operating system – Windows XP, Windows Vista, Windows 7, Mac OSX, Linux, etc.
Screen size – if relevant, can also be seen in the screenshot
Add helpful notes. Jot down whether the bug reproduces consistently or not, its importance or priority, and any kind of info and ideas that may be helpful.
Use clear language with correct spelling. Often people jot a bug and send it off immediately without thinking twice. Often the bug is illegible and I have to ask for an explanation. After writing the bug down, read it again, and make sure it makes sense. Edit it if it doesn’t, and please fix spelling mistakes as well to make your message even clearer.
Advanced – open the browser console and copy error messages. If a JavaScript or AJAX error happend or the application sent an error message to the console, this info will greatly help the developer. Copy-paste it into your bug description.
Hope this helps to improve communication with your neighborhood web developer. I’m sure he or she will appreciate it and that work together will improve greatly.
Working with web designers is an interesting process, to say the least. Most of them have an altogether different view of websites than web developers or user experience designers.
Sometimes this is for the better. Unfortunately most web developers lack any aesthetic skills whatsover. Unless you consider SQL table like web pages a thing of beauty. That’s actually a shame, and could be easily improved by reading books such as The Non-Designers Book. UX designers may have better aesthetics, but web designers are experts in this field.
Sometimes this is for the worse. Aesthetics, quite often, come in the way of functionality and user experience. Also, most web designers aren’t aware and knowledgeable enough of the entire web site development process. Not just coding, but also usability, marketing, and understanding both the client and her users. They just want to design pretty websites, according to their standards, and stay away from anything else involved in the process.
Hence, here are a few tips that could help website designers to improve their work process and avoid mistakes that will most probably show up as the project progresses:
Design for various screen resolutions. Not everyone has a big and beautiful iMac screen like you do. People will be surfing your site from laptops, desktops, maybe even mobile phones (though usually that’s a different story). In fact, the browser may not be open to full screen size. How will the site look on their screens? Take a look at browser display statistics and take it into consideration as you design the website.
Show sketches in the browser. Something magical happens when clients see sketches of their website in a real web browser. All too often they suddenly see things they don’t like about the design, even though they approved it themselves to begin with. Some of this may be unavoidable as people change their minds and see different things at different times.However, if clients would be able to sit at home quietly, open a URL, and see your sketch of their website in their favorite browser, I’m sure it would create a different reaction than seeing it in a sterile image viewing program. Heck, you could even create a nifty simulation of your client’s website using only screenshots with a little HTML and image map editors. At the very least, capture an empty web browser window, and stick your sketches there. It puts it in context and could save an iteration or two further down the road.
Consider image sizes. Quite often I see images in web designs that result in big files, especially backgrounds. This can look quite cool, however, it will also make the website slower to load. Not everyone has that 10MB connection. People are using the Internet in congested public wireless networks, via slow mobile connections, or are even downloading some big files in the background that are clogging up their connection.If the website contains big image files it will take longer to load, and the user may lose patience and click that good ol’ back button, so she will never see your amazing design. Aesthetics are important, but so is the practicality, and you should be well aware of it. At the very least, if you cut the images chose the right file format, and use a decent JPEG compression rate.
Learn about usability. It’s your job not just to create a pretty site, but also one that will be easy to use for all users. At the very least, please read the wonderful book Don’t Make Me Think. It’s short, very clear, and will give a boost to your usability awareness. For specific issues, I highly recommend Jakob Nielsen’s website and Googling of course.
Mark visual details for the web developer. One of the last web designers I worked with did something wonderful. She marked the exact margins, font sizes, link colors etc. in the screenshot itself! This provided me with exact info how to program the CSS and made my web dev life so much better and easier. If you’ll provide this info to your web devs they’ll love you, the website will get done a little faster, thus your client will be more satisfied.
Designers don’t like links. I swear. Again and again I see designs for web pages where links look exactly like text. Same color, no underline. Sometimes a color that’s too similar, rarely an underline.
My visual friends, this hurts the user experience. Links need to look distinct from the rest of the text, preferably via both different color and underline. If you don’t believe me, maybe you’ll believe Jakob Nielsen:
To maximize the perceived affordance of clickability, color and underline the link text. Users shouldn’t have to guess or scrub the page to find out where they can click.
It makes perfect sense. Lest we forget, users/we don’t read web pages, they/we scan them. While scanning you want to have a clear and immediate idea what’s linkable and thus clickable and what’s not. Having links that look exactly or similar to the regular text doesn’t support this.
Please, save the links. Let them strut their stuff. Give them a fancy color. Give them an underline. Hover over color isn’t mandatory. Just KISS.
