Web Design Sydney Melbourne | Wiliam Blog

Custom Twitter feed - Twitter API v1.1 - The death of API v1

Tue, 18 Jun 2013 00:00:00 +0000

So it’s dead, API v1 for twitter was put to bed last week: https://dev.twitter.com/blog/api-v1-is-retired

If you weren’t across this – your custom twitter feed that utilises the v1 API would cease to work and you would be trawling through various forums to find sweet FA about anything really….(until now that is)

So what do you need to do to get it back online?

Let’s start at the beginning, what changed to make so many developers scrambling to fix their now legacy feed:

The overview is here however in a nutshell twitter’s shift towards OAuth just got stepped up; you can no longer just slap a screen name at the end of REST call and receive a twitter JSON feed NOW you have create an app and initialise the twitter OAuth.

Quick steps to get you going

Log into twitter and go here & create an app

https://dev.twitter.com/apps

Once created we need these the values you need to initialise the OAuth:

Dependant on what techonology you used to consume the JSON – there are few open projects located here: https://dev.twitter.com/docs/twitter-libraries

I am simply going to demonstrate a JavaScript One: https://github.com/mynetx/codebird-js

As the documentation suggests – create the Open auth like so:

And make your feed call:

cb.setToken('YOURTOKEN', 'YOURTOKENSECRET'); // see above

cb.__call(

'statuses_userTimeline',

{‘screen_name’:’EXAMPLE SCREENAME’},

function (reply) {

console.log(reply);

}

);

Wiliam is one of Australia's leading web site design and web development agencies. Our Melbourne web design and Sydney web design offices provide cutting-edge Web 2.0, internet marketing, business web hosting, email marketing software, search engine optimisation, SEO, Facebook Applications, Link Exchange and SEO Tool services.

Improve the mobile checkout experience

Mon, 17 Jun 2013 00:00:00 +0000

Smart phone usage is on the rise in Australia. 37% of people owned a smart phone in 2011. This increased to 52% in 2012.

"Smartphones are critical shopping tools with 94% (of users) having researched a product or service on their device. Smartphone research influences buyer decisions and purchases across channels.

28% of smartphone users have made a purchase on their phone. Implication: Having a mobile optimised site is critical and a cross-channel strategy is needed to engage consumers across the multiple paths to purchase."

Source

With these numbers it's a must to get your mobile checkout experience right.

When collecting customer details, ensure only vital fields are included
Enable people to checkout as a guest if needed
Use touch controls rather than trying to make the user type
Remove any distractions that could drive the user elsewhere
Show progress bar in checkout
Make it light and make sure that the pages loads quick.
Make sure credit card security symbols are visible
And last but not least, test and test. Make sure you A/B test the pages

Uploading a file over an Ajax postback

Thu, 13 Jun 2013 00:00:00 +0000

None of my usual long-winded ranting this time around. Code. Just code.

Many people don't realise that most modern browsers are capable of uploading a file over an Ajax postback, something which can come in handy when you want to maintain a positive user experience and not resort to flash-based or html5 based uploaders.

How

1) The markup

  	 	Submit!

2) The Javascript

The magical stuff is the 'var dataString = new FormData(myForm.get(0))' line, in browsers that support it (more on that later).

$(function () { 	$('.form-submit-button').click(function () { 		var myForm = $(this).closest("form"); 		if (myForm.valid()) {  			if (typeof(FormData) === 'function') {  				var dataString = new FormData(myForm.get(0));  				$.ajax({ 					url: myForm.prop("action"), 					type: 'post', 					data: dataString, 					processData: false, 					contentType: false, 					success: function(result) { 						// handle the success result, set the html back in to a visible container 						myForm.closest(".form-container").html(result); 					}, 					error: function(jqXHR, textStatus, errorThrown) { 						// handle your error 						alert(errorThrown); 					} 				}); 				// it is important to return false in order to 				// cancel the default submission of the form 				// and perform the AJAX call 				return false; 			} else { 				// do a regular postback 				myForm.submit(); 				return false; 			} 		} 	}); });

3) Server side

Just handle the request as you normally would, nothing special here.

Browser Support

The central object for this mechanism is the FormData class in javascript. If it is not declared by the browser then you will not be able to upload files using AJAX. In that scenario you can choose to revert to flash-based uploaders or some other equally outdated method, but once you see the browser compatibility chart below you might just choose to fall back to a regular old full page postback.

Chrome 7+
Firefox 4.0+
IE 10+ (Haha)
Opera 12+
Safari 5+

So basically it's only the out of date IE users that will need the fallback behaviour, so you will need to decide for yourself based on the target audience of your site.

Adaptive/responsive technical and SEO considerations

Thu, 13 Jun 2013 00:00:00 +0000

The technical definition for the difference between adaptive and responsive websites is that adaptive websites alter their layout server side and responsive sites alter it client side.

Adaptive and responsive design have emerged from the desire to serve all the content of a single site from a single domain. While m. mobile domains did the job of making content accessible to mobile devices, they did have a number of issues arising from the fact that they were separate domains. Most importantly among these was Google detecting the same content on two separate domains and splitting the page weight.

While both adaptive and responsive design achieve essentially the same result, serving content to different profile devices, the way they function applies practical restrictions and best practice requirements on what can and can’t be done with each.

Adaptive

Modern browsers reveal a lot about their internal capabilities in the user agent string and other request headers however this is still not enough for a site to determine enough information to adapt its content. For this reason when creating an adaptive mobile site we need to use a device library in order to know the individual device capabilities. 51degrees is the industry standard in this regard.

It is also worth noting that changing the content of pages based upon the detected user agent was first used as a black hat SEO technique to known as cloaking. The goal was to show Google different pages to the end user. It is for this reason that whenever we do an adaptive site we have to set the “Vary: User-Agent” response header for all content pages. This tells Google what we are doing and since we are being upfront and honest about it we don’t look like we are cloaking.

This also helps proxy servers know that it should be caching a different copy for each user agent string. It is also worth noting that the header value should only be applied to the content pages, you don’t want proxies storing dozens of copies of you css and images. This can cause a significant bandwidth hit, especially when using an origin server style CDN.

Responsive

With this technique, the same html content is returned to all devices, it is css and javascript that changes the layout.

Due to the fact that all clients receive the same content this is the preferred method for creating SEO friendly mobile sites as there is no potentially deceptive content. It is, however, the worse technique from the client’s perspective since on the lowest profile mobile phone you are still downloading all the desktop site content, just hiding what you don’t need.

Within responsive design there is a further subset that we term fluid layout. In these layouts the transitions between the different layouts are managed using javascript animations and generally there are many smaller steps between the different layouts allowing the site to fit almost any device profile.

Integrating your .Net Console Application with Umbraco

Wed, 12 Jun 2013 00:00:00 +0000

One of the more common issues that comes up with Umbraco is how to access its data store and methods from an external source. This comes up when you have to build a console application or scheduled task that needs to perform system functions but have full access to Umbraco library. One way you could do this is try to remember all the .dll libraries and configurations necessary for the console application to access Umbraco, or you could use Umbracos Web Services instead.

It's really that easy. Umbraco already has built into to a bunch of Web Services that you hook into. To do so you simply load up Visual Studio and find the Solution or Application you would like to use the the service on use the Add Service Reference tool. Enter the URL of you local Umbraco instance and hit the Discover button. This presents you with some pre-built web services you can use built by Umbraco.

If you need to make something a bit more custom you can do so by adding a Web Service to the Services folder of you current project. From there you can build the Web Service to do whatever tasks you require and have them all leverage against the Umbraco library. Be sure to check for a Username and Password on all your Web Methods as these services are public. Once your done and its all tested you can then reference the new service from your outside application without worrying about .dll libraries or other includes. Just call the new Web Service and have all the work done at the Umbraco end while your application takes 5 and waits for the response.

Happy Coding.

Why m. sites are not good for your website

Wed, 12 Jun 2013 00:00:00 +0000

Firstly, we all know what the differences are between a Responsive and an Adaptive website, don’t we?

Listed below are my main concerns in regard to websites that have a mobile version, the m.yourdomain.com.

1. Duplicate content SEO issue

Google, the king of web etiquette, has made it very clear that the optimal solution for a website is: 1 website, 1 Domain/1 URL, 1 page, allowing any device to access it the same way.

If you have a mobile website with a different domain (e.g. | m.yourdomain.com) then in Google’s eyes, unless you have taken the correct approach, your site will stumble on the “Duplicate Content” issue and you will be penalized.

By ‘penalized’ by Google, I mean pushed down the search results. And that sucks. You’ve worked hard to be where you are on the ladder, so don’t fall off.

How can I to prevent being penalized?

Something you should look into is helping Google index your mobile site.

Update your Robot.txt to allow “"Googlebot-Mobile” review your mobile site. More information on this here.

Another approach is to update all the canonical URLs. Here’s how.

2. URL Spaghetti

Let’s have a look at the CatchOfTheDay.

The mobile site looks good, it’s easy to use, but if I want to share a product to my mate Rob in the office, you’ll fall on the URL spaghetti issue.

This will be what you’ll see on your mobile device:

This is what Rob will see in the office:

Desktop same Page

Instead of

And for Rob it is actually impossible to go from the first URL: https://m.catchoftheday.com.au/product/22242/159362

To the one for desktop: http://www.catchoftheday.com.au/event/22242/product/nike-men-s-downshifter-5-grey-yellow-159362

3) Email redirect and content issue

Managing 2 websites is also more expensive than managing one. This is why some sites don’t have all the pages.

So if users on mobile devices can’t access pages, the options are to leave (very easy), or go the the “main” site and tap around a terrible user experience (very frustrating).

Check out this email LinkedIn sent me…

Once I click on the link, this is what i have to deal with…

Come on LinkedIn, you’re better than that!

5. Cost

On average, planning a new site and integrate a responsive layout is 10%-20% more expensive than the initial build, and for any future changes you only need to add a 20%-40% extra time on slicing and testing.

Compare that to having to update two websites all the time, where any changes are 70%-80% more expensive every time you need to update your site. And that’s for the rest of the life of your mobile website.

Are you really saving m.money now?

Some of the latest results from Visual Web Optimizer. Some of these are obvious but still interesting.

Fri, 07 Jun 2013 00:00:00 +0000

Always lead the user to where you want them to look. If you want a user to look at a product then focus the attention of imagery to that point. The example below has a picture of a girl looking at the product which generated more user activity to the product. The same can be said for using arrows to point users to where you want them to look.

Make sure the call to action is relevant to your business. If they are going to get a pricing sheet then make sure you use that terminology.

Be upfront about costs. The reality is people price match online and hiding pricing from a user is only going to make them find a site who doesn’t. If your prices are competitive don’t be afraid to promote them.

Live chat is a no brainer. Even if you are not always online the concept of live chat alone will increase your leads. If in doubt you can always switch it off but you will not regret adding it as an option to your site. Third parties such as livechatinc (www.livechatinc.com) make it incredibly easy to add this feature and qualify leads making it easier to convert the visitor into a lead.

People are used to modal windows these days so it is less of a difficult decision to add one to your site. If you want more leads then a modal is a quick and inexpensive way to do so. Make sure you offer an incentive to filling it in.

Testimonials on signup pages generate interest. It gives the user an idea of the type of content they will receive in your newsletter and creates excitement. Make sure the testimonials look realistic and highlight a feature of the newsletter.

Cross browser testing gets easier: BrowserStack

Fri, 07 Jun 2013 00:00:00 +0000

Testing across browsers is something that web developers just have to do. There is no way around it. Browsers have improved considerably since the age old days of IE 5.5, but there are still differences between how some browsers choose to render a page – worse still, sometimes a specific combination of browser and scripting technology can completely change how something functions.

Enter BrowserStack: www.browserstack.com

Created by the good people at StackExchange and endorsed by Microsoft themselves over at www.modern.ie (where you can get a 3 month free trial, for a limited time), BrowserStack is a paid monthly service that allows you to fully interact with hosted instances of all major browsers: Internet Explorer 6 and up, Chrome, Firefox, Safari and Opera on all platforms, including Mac and even smart phones. And it’s not emulation like the compatibility mode options available in IE.

It works by utilising a combination of browser Java plugin and Adobe Flash, and by spinning up remote virtual machines as required. It is really no different to using VNC or Remote Desktop into another computer. The included browsers even have Firebug installed for debugging any issues that arise.

The best part? By creating a tunnel to your machine (all done through the interface), you can test your local websites. No need to deploy anything to a staging server!

Browser options differ depending on the operating system chosen – to test IE6 you spin up a Windows XP virtual machine, or Safari on a true Mac OS X install.

So what’s the cost? Very reasonable in fact, especially when purchased for a team by a web development agency. As an example, a small agency could outfit their whole team of developers for $79 per month.

And there’s even a handy plug-in available for Chrome and Firefox!

If your team adopts BrowserStack as part of their regular development cycle, it could be considered the best new tool since Firebug and the Red-Gate toolbelt!

Using the AWS SDK to create an S3 connector

Tue, 04 Jun 2013 00:00:00 +0000

I was looking for a file manager plugin for CKEditor or TinyMCE with S3 support. There was nothing decent available. Well, nothing in the .NET space anyway, it was all in PHP, even the licensed file managers. So I decided to write my own. I was already using CKEditor with Core Five Labs’ file manager, so all that was needed was to create an S3 connector for it.

Upon examining the AWS SDK, the first thing you notice is the similarities between System.IO namespace and the classes in the SDK. For instance

var dirInfo = new S3DirectoryInfo(_awsClient, _bucketName, path);

var dirInfo = new DirectoryInfo(path);

The S3DirectoryInfo object has an equivalent of the well know GetFiles/ GetDirectories method found on the System.IO objects. Obviously it’s not a 1:1 mapping against the two frameworks, for instance, the AWS doesn’t have a Created Date for its files/directories. There are enough similarities though for migration to be an intuitive process, there wasn’t a need to look up the documentation at all. In the end, my S3 connector centred on the use of 2 classes from the AWS SDK:

S3FileInfo

S3DirectoryInfo

I would say the AWS SDK makes interacting with S3 a walk in the park with an intuitive migration path from .NET’s System.IO to AWS SDK. It even comes in NuGet form!

ASP.Net Health Monitoring and Logging

Tue, 04 Jun 2013 00:00:00 +0000

As you probably know, when it comes to logging there are a lot of application add-ons out there used such as Elmah, nlog and log4net. What you may not know, is ASP.Net has a lot of handy logging features for automatic events straight out of the box ie.

Heartbeats
Application Lifetime Events
Request Processing Events
All Errors
Infrastructure Errors
Request Processing Errors
All Audits
Failure Audits
Success Audits
All Events
And Custom Events

By utilizing these events, your application can be configured to handle capturing and logging process diagnostics (e.g. your applications current managed heap size), application life cycle events, application login attempts, server errors etc.

These events can be configured to log to the event viewer or SQL server or the WMI Consumer(for custom applications to monitor).

The setup is pretty basic. Your machine web.config will by default be using Health monitoring to log errors to the event viewer for all server errors and failed login attempts. To extend this, to for example log the heartbeat event for process diagnostic info, add the following lines to the system.web node of your application web.config.

<rules>

rules>

healthMonitoring>

Note: the heart beat interval determines the frequency of the Heartbeats event getting raised.

Now to view the logs, visit the windows ‘event viewer’ and navigate to windows logs -> application as below:

As you can see now have logged a snap shot of this applications current requests executing, requests rejected, managed memory heaps size and more.

Enjoy!

Mobile first? Give it six months…

Thu, 30 May 2013 00:00:00 +0000

There is an ongoing debate in our office about when we will design a website though exclusively around mobile

It can’t be far away.

Already, we start our projects thinking about mobile first if only that it really underpins great usability across of devices and screen-sizes, right through to desktop.

An article out this morning is just another nail in the coffin of the desktop internet being the king. Have a look at the presentation embedded in the article; a really good read about where we are right now.

Mobile is accelerating on all fronts and desktop is not. 2013 is truly the year of the mobile.

Why your website probably isn't the problem

Wed, 29 May 2013 00:00:00 +0000

I met with a fairly successful eCommerce website last week.

In fact, in their category, they’re the largest player in Australia and growing at a nice trend.

This said, they don’t feel their growth is quite on the right trajectory, especially as they feel they’re seeing growing ‘exit-rates’ from their website and less sales as a percentage of customers.

Fair enough a point, at least at first glance; something is wrong with their website and increasingly.

As web designers, we have been trained to immediately hone onto any given website and to find faults in construction, usability and performance as the basis of any undue underperformance.

We look at the colour of buttons, the size of text, whether content is above ‘the fold’ and so on; and required to come up with an answer for why a website is not sprinting in terms of performance, we naturally find blame in the website.

And it is true that even the most optimised websites will contain inherent faults hindering sales and performance.

But is the website all that is at fault?

Think laterally

I am in the throes of purchasing a Chiminea (an outdoor, Mexican fire-pit) for home:

My old Bunnings Chiminea – made of clay – finally caved in on itself after many outdoor fires and so determined to find something more long-lasting, I turned online.

The quality of websites selling Chimineas in Australia (and really anywhere) is atrocious and predictably so.

But the appalling nature of these Chiminea websites hasn't stopped me from browsing and enquiring.

Sure, if the different Chiminea websites I have looked at were actually ‘functionally’ broken, I might not have made the enquiries I did, though save for looking visually terrible, the websites worked functionally fine.

Which, in my opinion, supports the notion that what a website looks like is not really what determines whether the website will work or not.

Over and above this notion, I sometimes refer to a concept I call ‘user perseverance’.

My concept is simply that under certain circumstances, users will actually put up with a poor experience, merely because they think they need to (i.e. you’re the exclusive seller of a product) or because they have to.

As a good friend of mine who works for a major insurance company, pointed out to me that despite the atrociousness of his company’s mobile offering to customers (i.e. mobile users have to use the desktop website), the conversion rates across mobile and desktop were consistent; if a user needs car insurance and they need to organise it on their mobile, they’ll slug their way through it.

They’ll persevere.

Indeed, my friend pointed out that whilst many web designers had pitched him on improvements to poorly-performing parts of his website in terms of sales and ‘conversion’, my friend’s research in fact revealed that the real reason the a certain part of his website wasn’t performing was because people do not purchase discretionary insurance online.

Having built a few insurance websites – especially in life insurance – I can assure you that this is correct; the website isn’t the issue, the product is.

“People don’t buy life insurance. They’re sold life insurance.”

Which brings me to my point of being and thinking lateral about your digital business.

Optimising a website in of itself, is a great and important thing.

But there are many other factors at play in a digital business.

And it is these many other factors that are often ignored.

Do you have the right range and enough range?

How is your pricing?

Is your content mix right?

Is your messaging consistent with your users need and want?

Are you better to get your users onto your call centre?

These are just a few questions you might ask yourself, though as I speak to my clients this year, it’s clear that the trend for 2013 is that ‘it’s not the website that’s broken’.

It is everything around it.

Conclusion

As keen as I am to sell anyone a new website, that might well not be your digital boggle.

Sure, at the hyper-level of selling that ASOS and eBay and Amazon work at, there is an unquestioned and constant program of website optimisation and improvement.

But these companies are focused right across the whole gambit of their businesses.

For the rest of us, we naturally have a more narrow focus by the mere fact of having less resources and capability; we can only focus on one or two things at once.

What I am suggesting is taking a more holistic view to your digital business than simply focusing on the website and its ‘conversion’.

Buy some reports.

Get a consultant in.

Talk to your users and ask them about your broader offering.

Look at your competitors and understand their strengths and weaknesses compared to yours.

Do a customer journey map and understand the sentiment of your users from the very outset that they encounter you.

By all means, keep plugging away at improving your website, though it is very arguably not what is broken.

WebP pushes image compression further

Tue, 28 May 2013 00:00:00 +0000

Image compression has fallen on the backburner the last few years. The rise of streaming video across the Internet has pushed focus to video. Rightfully so, the approval of video standard H.265, is a huge step forward in video compression.

Video aside, much of the web is still made up of images.

Thankfully, some of the advancements of video flow down to images. After all, a video is just a set of still images. Well, in the world of video compression, not really, but there are shared compression methods.

Image compression has been traditional made up of two methods:

Lossy – compression that discards image detail to reduce size.
Lossless – compression that reduces size but maintains detail by describing an image as an algorithm.

In the simple terms, JPEGs are lossy and GIFs are lossless.

Lossy sounds bad, but for photos is easily to best way to strip (unnoticeable, or tolerably noticeable) detail. Lossless of compression of photos doesn’t save my space at all.

Google has set about to merge both these compression formats in its recently updated WebP format. Doing so has seen file sizes about 33% less than JPEG for a comparable image.

CNet have a couple of examples here

Historically only supported by Google, the recent update has added features such as EXIF data and alpha transparencies that’s got Mozilla on board too. Getting Mozilla across the line was always going to be the easy one though, Microsoft and Apple will be much more difficult.

Whether WebP takes over the world or not is up for debate. However, anything that shakes up the other formats to think about same level of enhancements we’re seeing out of video, is a good thing in my opinion.

Controlling the mobile device view port

Fri, 24 May 2013 00:00:00 +0000

Controlling the view port size of a mobile device is a relatively easy thing to do. The hard part is deciding the scale and how much control to give the user in adjusting this scale.

The view port is controlled by adding a meta tag to the head of your page:

Using a combination of properties to control the width and scale of the content we can essentially scale the size of which a pixel is rendered on the device.

The meta tag above sets the width of the content equal to the width of the device. This is not to say that your 960 pixel page becomes 768 pixels wide on a small device, it sets the device to display the 960 pixels across the devices 768 pixel screen. A pixel therefore becomes 80% of it's actual size (768 / 960 = 0.8)

Setting minimum and maximum scales tells the device what the safe zoom-in and zoom-out size is. Above, the properties tell the device to not allow any zooming at all.

Interestingly the "viewport" meta tag isn't yet a W3C standard. Given the demand for the tag (it is supported by all popular mobile browsers and used by thousands if not millions of websites), there is now a specification in draft as of 7th May 2013, http://dev.w3.org/csswg/css-device-adapt/ This new specification quite rightly moves the control from the "head" element into css.

@-viewport {

width: 640px;

Combining this with media queries one would in theory be able to normalise screen sizes based on the content styles to be rendered.

@media (max-width: 699px) and (min-width: 520px) {

  @-viewport {

    width: 640px;

This css would normalise any screen smaller than 700px and larger than 519px to display as though it were 640px wide.

The new spec also allows similar (but more advanced) scale properties along with a new orientation property. So far IE10 is the only browser to even partially implement the new standard, allowing one to set the width and/or height properties.

Using Pseudointernationalisation to test internationalised sites

Fri, 24 May 2013 00:00:00 +0000

Pseudointernationalisation is the process of creating a pseudo-translation set for your content and resource files. Not only does this help you to locate any UI elements that have been hard coded into the UI, it will show how different string lengths affect the layout of the site. Additionally it will test your site with extended character sets. The process itself is really simple.

Pick a language that your site will most likely not utilise.
Create a set of obviously fake set of translations for that language.
Switch your site to use the language (by whichever language switching mechanisms are available to your site)
Observe the new layout and go from there.

Your overall strategy will change depending on the target languages, but of course, the closer you can simulate these languages the fewer anomalies you will have on your production site. There are general rules of thumb, and statistical data that you can use to help you get close. For example, a short word in English will translate to something 4 times as long in some Latin based languages.

To help generate these translations, you can use Psuedoizer. Psuedoizer is a really simple tool that takes a few of these rules into account, generating the translated content for you. It’s a console application that will convert your RESX files into a pseudo-translation. The pseudo-translation is essentially English substituted character for character from the extended character set. For example, an English ‘B’ will become a Greek Beta. It will simulate extended length by padding the translations. The benefit of using pseudo-English is that the site is still readable. And you get full access to the source, so you can easily incorporate translations into your data seeding mechanism for your test environment.

Being a console application, it can easily be included as part of a build script. You can get the Psuedoizer tool here: https://github.com/shanselman/Psuedoizer

Watermarking digital photos

Fri, 24 May 2013 00:00:00 +0000

Watermaking digital photos online it extremely important for certain clients, particularly in the art space. We have recently been developing an amazing art gallery website where by the images of the artwork not only are under copy write, they also have local beliefs behind them which prevent them from being miss-used online. When we did a google image search almost every image we found on the current site had been taken and used on other sites so it was imperative that the new site had stricter restrictions on copywriting in place.

One of our developers spent time researching the best way to watermark digital photos (apparently called Steganography) and this is what he found:

We can read that text back from any image using software that we create software.
Therefore we can create a page where images can be loaded in and checked to see if they have been copied from the original image on the site.
However, if a user opens that image in Photoshop, resizes it and hits save, the copyright text is lost

Adobe has a thing called XMP that is part of Photoshop. It’s so you can add Copyright, Author etc. when you go File > File Info in Photoshop itself.

You can apparently code to this but it looks like a large tasks. There doesn’t appear to be a native .NET implementation.
A user can still remove this text in Photoshop by just clearing the field

The industry standard for doing this kind of work is Digimarc - http://www.digimarc.com/

This is not an API and not something we can access programmatically. It’s an application you use to process images before uploading them to your website.
It is a subscription service. They have a ‘copyright search engine’ that searches the web for images you watermarked using their program. This appears to be the most sophisticated way to do this however there is no easy way to make it work with your existing CMS.

Photoshop CS6 = My new love.

Fri, 24 May 2013 00:00:00 +0000

We have just upgraded to the latest Adobe suite here at Wiliam, and with that came my new love - Photoshop CS6. I don't even know where to begin explaining how much I love this updated version and how much it has made my life easier when designing.

I have a feeling Abobe was tracking how people worked on pervious versions and added new features and tweaks to better our experience.

The first thing I love about Photoshop CS6 is it's enhancement to the crop tool. Now the whole canvas is preselected, which is such a big help. It reduces the number of steps needed to alter a canvas size. I know everyone has a different way of doing things in Photoshop, previously I used to click and drag the tool from top left to bottom right, then pull it down to extend my canvas. Now I just pull it down. Perfection.

Another small but life changing enhancement preselected state of the hex code within the colour picker tool. Again this cuts out so many added steps if you wanted to paste in a colour from a brand guideline. Previously, you would have to select the text manually, delete it and then paste. All you need to do now is open the tool and hit paste! Heaven.

Before Photoshop CS6, I would have to keep the Information tab constantly open in order to measure out how many pixel there were between elements. Not anymore! The marquee tool now comes with the Head Up Display system which shows you the measurements as you pull the tool over your canvas. Genius.

I am still yet to try out the new Paragraph and Character Style panels. But I know it will again cut down time when trying to keep headings/text consistent through PSD's. I have to applaud Adobe on their latest release of Photoshop CS6. I didn't think it would have such an impact on me since CS5 was not that much better/different than CS4. Adobe have done so well, I can't wait to try out all the features.

Forcing secure viewing over https in MVC

Fri, 24 May 2013 00:00:00 +0000

Suppose you want your application to automatically adjust, to view a page of your application over https even when a user attempts to view the page over http. This can be achieved quite easily with ‘ActionFilterAttribute’ in mvc.

To do so requires 2 simple steps. Firstly, add the following class to your web project below:

public class SecureAttribute : ActionFilterAttribute

{

public bool PermanentRedirect { get; set; }

public override void OnActionExecuting(ActionExecutingContext filterContext)

{

var request = filterContext.HttpContext.Request;

if (request.IsSecureConnection) return;

string redirectUrl = request.Url.ToString().Replace(

Uri.UriSchemeHttp,

Uri.UriSchemeHttps);

filterContext.Result = new RedirectResult(redirectUrl, PermanentRedirect);

}

Now all that’s left, is to open up your controller class and specify the attribute either preceding the action method, or before the controller class declaration.

Eg.

[SecureAttribute(PermanentRedirect = true)]

public class AccountController{

….

public ActionResult Register(){

}

And that’s all that is necessary. Now if someone tries to visit http://yourdomain.com.au/Account/Register, they will be permanently redirected to the same url over https.

Umbraco gets easier with MVC

Fri, 24 May 2013 00:00:00 +0000

Working on Umbraco sites over the past couple of years has been a love/hate relationship. In the beginning it was one of those tools that had to be figured out with much digging into the code and the framework to achieve the smallest result. Once you found how something worked it all seemed to make sense. There were features that were easer than others and some harder than they should have been, like getting an image from the media library.

The good thing is with the current version and using MVC it has become even easier as a .NET developer. As most websites these days have moved on to the MVC framework it was a good decision of the Umbraco team to embrace this concept too. No more web forms and fiddly post back controls. It is now all about Models, Views and their Controllers. Makes things so much easier, now I only have to learn how to grab those media items again.

Dipping my toes into Responsive Design

Tue, 21 May 2013 00:00:00 +0000

My first experiences with responsive design was by being thrown in the deep end. That’s always the best way, I find, and is even more interesting when the bulk of the work has already been done. From looking at the already created CSS and JavaScript from a project I am now co-developing I have learned the basic techniques for creating a responsive template for tablet and mobile devices – and it really isn’t that hard.

The key lies with the CSS media selectors. First, construct your CSS for your desktop view as you normally would – though keep the tablet and mobile views in mind when deciding how to construct your HTML. When it comes time to create the mobile template, insert the following into your CSS file AFTER your main CSS declarations.

@media only screen and (min-width: 300px) and (max-width: 767px) {

}

This is a media selector, and this one defines the rules for browser width that represents a mobile device such as a phone. Within the declaration simply override your main CSS declarations with their mobile equivalent.

@media only screen and (min-width: 768px) and (max-width: 1000px) {

}

These widths define most tablet devices. You will notice that when you resize your browser to the defined widths, the template realigns itself and obeys the new CSS rules. You could also include mark-up specific to a media by decorating it with a class, such as “mobile-only”. In your base CSS you would set display: none, and in your mobile media selector set it back to display: block. This is an easy way to add and remove elements not required for all templates.

The most important thing to remember (as is usual with modern web development) is that Internet Explorer version 8 and earlier (and some earlier versions of Safari) do not support media selectors. Our salvation lies with the jQuery library “CSS3 Media Queries”, found here: https://code.google.com/p/css3-mediaqueries-js/. Just include the script and you are good to go.