⭐ If you would like to buy me a coffee, well thank you very much that is mega kind! : https://www.buymeacoffee.com/honeyvig Hire a web Developer and Designer to upgrade and boost your online presence with cutting edge Technologies
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts

Thursday, December 8, 2022

Network cable management and mapping switch ports

 

Keeping a track of computers that are all connected to a network can be a hassle, without desktop management software. Even with it, you can’t necessarily tell exactly which physical computer is connected to a given switch port. Eventually, you will come back to a switch closet, but this doesn’t necessarily help the situation at all; especially when you encounter a stack of Cisco 3750s, spewing yellow ropes of technological vomit off in all kinds of directions. So the best things you (we) can determine are a wall socket (if it is labelled) and maybe a MAC address too, if you log in.

But this is all a heap of work that just shouldn’t have to be done at all and really frustrates, further, any problems that you’re trying to troubleshoot. So, I decided to come up with a plan. This is quite a long post, but it gives background to what motivated me to do this in the first place!

Standard problems:

In lots of situations, you’ll know what the cause of a network problem is. In some cases, we notice connection issues across the board and it is likely that the problem is already known by the IT services department. Specific PCs with issues can often come down to the issues below:

  • DHCP scope has been exhausted, so no more IP addresses can be given out
  • Port is disconnected (no signal)
  • Port is shutdown (electrical connection is present but no traffic goes over the wire)
  • VLAN mismatch (subnets of specific PCs will be assigned differently than that designated to the rest of a given room)

(This is just going to go and assume that a PC has been physically checked that it is connected to the right network interface (each interface has a different MAC address which can affect FOG host registration settings and port security settings on a switch) and is connected through the correct wall port that was assigned to that PC (or to a port that we know is – or should be – assigned to a specific network)).

In the case of a DHCP scope issue, the problem can be partly determined by the PXE boot message popups, for example it may display a message that it is receiving proxyDHCP offers but not DHCP offers. If a port is disconnected, this can be determined through a network cable tester. A shutdown can be determined in a similar fashion (electrical signal present but no traffic received) but in all these cases, the only information that can be provided to IT services, that would be of any use, are a patch panel port number and a system MAC address. However, these won’t necessarily help in determining the right location of the switch in a building that has possibly 100 or more switches around.

The case could even be that a PC may work fine and even connect to the internet with no problem – but then if a room of 30 PCs were to receive multicast traffic on a system and, say, two or three are on a different subnet, multicast issues will present themselves and PCs may stop imaging before others have finished. In fact, it is only if someone knows the symptoms and has had experience with the last issue – VLAN mismatches – that you can really identify that as the cause of the issue.

Working with others

Now, in this environment, all PCs are allocated an IP address in specific subnets that corresponds to a respective VLAN, which in turn corresponds to a room (usually). VLAN configuration is implemented by switches. If we want to check some of this information to see what has been – perhaps incorrectly – configured, then we need to be able to access the switch configuration. As these switches are (almost all) operated by the IT services people, our team cannot see this configuration. Even if we were given the configuration, it would eventually become outdated, especially as things can be disconnected and reconnected by other people.

So we could be simply stuck at only being able to provide patch panel numbers (the wall sockets that a PC is connected to), a room number that the PC is in, a MAC address of the PC and an IP address. With the MAC address, IT services could possibly find out where a PC is connected to if a MAC address is provided, but this information is not readily available unless we provide it – and this is assuming it will be accurate and never change. Plus this presents another issue; if the configurations are stored on switches, how can any of the information we provide correlate to what is stored on a switch? The answer is it can’t – unless someone can trace a computer back to a switch port or someone can produce a mapping of this information and stores it elsewhere.

What has been tried

In our networking environment, all computers are connected to switches. Most importantly, this means that, regardless of all cables and panels, there is a direct link between a switch port and a PC. These switch ports are where VLANs are assigned to and where any port security will be set on. Therefore, being able to identify what is connected to all switchports is highly valuable – arguably to both IT services and our own technical team.

When there is an issue with a port or a PC, somebody has to trace that port back. If a port is broken, someone has to go to where the switch is physically located and trace back the cable from the switch-end of a patch panel to the switchport. As mentioned at the beginning, this is a nightmare approach, but it still has to be done.

However, this method is just too labourious for my liking. So the next thing to try is to use something called a fluke tester. These devices, which I think cost way too much money (even second hand they appear to be going for around £1000 – £1500 at the time of writing) for what we would be using them for, can be plugged into a wall socket and tell you all sorts of information about what is on the other side. Crucially for us, they tell us the switchport number and the switch IP address. This is actually brilliant and – whilst this method also requires manual work – is far more accurate. In conjunction with collating a list of wall ports, it can be used to accurately map out switch port to patch panel mapping.

This actually worked very effectively and, by late 2013, I had finished making a chart of many of our labs and detailed this on our internal wiki site.

wikitab

The idea was for part of it to be updated and maintained by our IT services and part of it by our department; we would make sure that PCs were in the correct position according to our own records for lab checks and that they were plugged into a corresponding wall socket. But this requires extensive user input and, predictably, will be prone to user errors. It was also pointed out to me at the time, when I borrowed the Fluke tester, that this collation of patch panel/switch port IDs had already been done by some interns and was now almost certainly already outdated. Nevertheless, I finished the mapping and maintained our side of things as changes were made.

And then changes were made that completely invalidated the entire chart.

Over the summer period in 2014, we had a network upgrade that saw the replacement of over 100 switches around the campus. Whilst no word to this effect had been made, it seems as though the switch configurations were probably from over a year ago – before any requested changes to the configuration had ever been made. With absolutely no communication about the upgrade or what might have happened, this presented a huge issue when upgrading our imaging system as it was slowly realised that there were a lot of small – with minimal overall impact – issues with the network configuration.

A new solution

It is clear by now that something more than just checking each PC individually needs to be done. This method is still viable for single sytems that might have the odd issue here or there, but to ensure 100% accuracy across all our systems there needs to be a different approach.

Wireshark provides a really cool piece of functionality that could help. Actually, this was what I have been using for about a year since I realised that it can be used to filter out LLDP and CDP packets after I noticed that the Fluke tester would pick up its information through these two types of packet (LLDP packets are broadcast every 30 seconds and CDP packets every minute across our network). The structure of these packets is very different (CDP uses an Ethernet frame and LLDP uses an Ethernet II frame) but both contain VLAN information, Switch information (for example IP, platform, version) and.. the switchport ID. This is accurate, it can be run on all PCs and we can get more information (VLAN ID, for example) than the Fluke tester would give us (I think it must be able to pull VLAN information out but I didn’t work out how to when I had a go with the one we used for a couple of weeks).

It is progress, but it was still intensive to do it this way, even with 4 or 5 people helping to go around a room. So can this be scripted?

If you strip out the GUI and just look at what Wireshark does, its functionally very similar to the Linux tool tcpdump which has a Windows port, WinDump (Actually, it is built using the same fundamental protocol – WinPCap, which itself is a port of libpcap). So in late 2014, I went about seeing what I could do to script WinDump and found through some quick googling that I could capture an LLDP packet or a CDP packet and then stop the capture after outputting the results of this one packet to a text file. This is great, although the formatting of the file isn’t particularly useful and would require some additional post-processing.

Windump curiously hasn’t implemented a nice formatting for LLDP packets and I would like to be able to utilise either CDP or LLDP outputs in a nice way – or really any network protocol. The only consistent way to output data is in the form of hexadecimal values. Both CDP or LLDP packets should output in the same format if the hex option is specified, but then what? There is still the issue to do with efficiency of data collection and obtaining the meaningful information – you still have to have somebody actually collect these results. The logical thing to do is to perhaps extend such a script to upload the output to a central server, but then I would have to process all of these text files and pick the useful information out.

So why not just do that processing on the PC before sending it? This is possible with a script, which could perhaps dissect an output text file – but with developing complexity, I decided that it could be a good idea to – instead – make a bespoke application that would actually grab all of this of data and upload only the useful parts that I want. Furthermore; rather than uploading a file, it would make sense to upload a record to a database that can store all of these results, foregoing any human interaction and even without needing WinDump at and only capture the relevant data we want in the first place.

So my work on this project, when time permits, has been to write a C (or C++) command-line application that utilises libpcap/winpcap – just as Win/TCPDump or Wireshark does – to capture either a CDP or LLDP packet and upload a string of text from that containing the switchport, vlan, hostname and IP address to a central database. So far it works quite well and hopefully will be releasing it for people to test out before making the source code freely available. I hope people can contribute to and help improve it and make it a genuinely useful tool for sysadmins across multiple platforms.

Edit: It could be suggested that I find out about connected hosts from the switches themselves or by using SNMP. The thing with various “switchport mappers” out there, however, is that they mostly seem to rely on using SNMP only. If you query a device that runs SNMP, you don’t necessarily get any more information than you would if you were to just look at that device yourself (for example, you can see all of a Cisco switch’s interface details to see host mac addresses; this is all you would receive back if you interrogated it with SNMP anyway).

What this program does, however, is a bit different. Whereas SNMP will give you a network map from the switch-side, this application will generate more detailed host information from the client-side. Switches won’t know a host’s IP address in all likelihood and certainly not hostname or any other information that you might want. Although you can find most of this out with other applications, this program will combine its own information with that given to it by a switch.

Of course, having the SNMP-derived information about a switch actually is not un-useful; this way, you can see every device that is connected to a switch, whereas what I have developed will only show you the information about hosts that you have run this application on (or that you can have remote access to, or have imaged with it already on and scheduled). It is quite possible in an environment such as the one that I work in that you can have other devices that you don’t have access to (AV and Wifi access points for example) and so you can’t make assumptions about free space on switches. So for the future, perhaps some SNMP integration with this application would make it a step beyond what most switchport mappers would normally provide (without being overly complicated). I guess this could help direct what the name should be, a bit more..

Network cable management and mapping switch ports

 

Keeping a track of computers that are all connected to a network can be a hassle, without desktop management software. Even with it, you can’t necessarily tell exactly which physical computer is connected to a given switch port. Eventually, you will come back to a switch closet, but this doesn’t necessarily help the situation at all; especially when you encounter a stack of Cisco 3750s, spewing yellow ropes of technological vomit off in all kinds of directions. So the best things you (we) can determine are a wall socket (if it is labelled) and maybe a MAC address too, if you log in.

But this is all a heap of work that just shouldn’t have to be done at all and really frustrates, further, any problems that you’re trying to troubleshoot. So, I decided to come up with a plan. This is quite a long post, but it gives background to what motivated me to do this in the first place!

Standard problems:

In lots of situations, you’ll know what the cause of a network problem is. In some cases, we notice connection issues across the board and it is likely that the problem is already known by the IT services department. Specific PCs with issues can often come down to the issues below:

  • DHCP scope has been exhausted, so no more IP addresses can be given out
  • Port is disconnected (no signal)
  • Port is shutdown (electrical connection is present but no traffic goes over the wire)
  • VLAN mismatch (subnets of specific PCs will be assigned differently than that designated to the rest of a given room)

(This is just going to go and assume that a PC has been physically checked that it is connected to the right network interface (each interface has a different MAC address which can affect FOG host registration settings and port security settings on a switch) and is connected through the correct wall port that was assigned to that PC (or to a port that we know is – or should be – assigned to a specific network)).

In the case of a DHCP scope issue, the problem can be partly determined by the PXE boot message popups, for example it may display a message that it is receiving proxyDHCP offers but not DHCP offers. If a port is disconnected, this can be determined through a network cable tester. A shutdown can be determined in a similar fashion (electrical signal present but no traffic received) but in all these cases, the only information that can be provided to IT services, that would be of any use, are a patch panel port number and a system MAC address. However, these won’t necessarily help in determining the right location of the switch in a building that has possibly 100 or more switches around.

The case could even be that a PC may work fine and even connect to the internet with no problem – but then if a room of 30 PCs were to receive multicast traffic on a system and, say, two or three are on a different subnet, multicast issues will present themselves and PCs may stop imaging before others have finished. In fact, it is only if someone knows the symptoms and has had experience with the last issue – VLAN mismatches – that you can really identify that as the cause of the issue.

Working with others

Now, in this environment, all PCs are allocated an IP address in specific subnets that corresponds to a respective VLAN, which in turn corresponds to a room (usually). VLAN configuration is implemented by switches. If we want to check some of this information to see what has been – perhaps incorrectly – configured, then we need to be able to access the switch configuration. As these switches are (almost all) operated by the IT services people, our team cannot see this configuration. Even if we were given the configuration, it would eventually become outdated, especially as things can be disconnected and reconnected by other people.

So we could be simply stuck at only being able to provide patch panel numbers (the wall sockets that a PC is connected to), a room number that the PC is in, a MAC address of the PC and an IP address. With the MAC address, IT services could possibly find out where a PC is connected to if a MAC address is provided, but this information is not readily available unless we provide it – and this is assuming it will be accurate and never change. Plus this presents another issue; if the configurations are stored on switches, how can any of the information we provide correlate to what is stored on a switch? The answer is it can’t – unless someone can trace a computer back to a switch port or someone can produce a mapping of this information and stores it elsewhere.

What has been tried

In our networking environment, all computers are connected to switches. Most importantly, this means that, regardless of all cables and panels, there is a direct link between a switch port and a PC. These switch ports are where VLANs are assigned to and where any port security will be set on. Therefore, being able to identify what is connected to all switchports is highly valuable – arguably to both IT services and our own technical team.

When there is an issue with a port or a PC, somebody has to trace that port back. If a port is broken, someone has to go to where the switch is physically located and trace back the cable from the switch-end of a patch panel to the switchport. As mentioned at the beginning, this is a nightmare approach, but it still has to be done.

However, this method is just too labourious for my liking. So the next thing to try is to use something called a fluke tester. These devices, which I think cost way too much money (even second hand they appear to be going for around £1000 – £1500 at the time of writing) for what we would be using them for, can be plugged into a wall socket and tell you all sorts of information about what is on the other side. Crucially for us, they tell us the switchport number and the switch IP address. This is actually brilliant and – whilst this method also requires manual work – is far more accurate. In conjunction with collating a list of wall ports, it can be used to accurately map out switch port to patch panel mapping.

This actually worked very effectively and, by late 2013, I had finished making a chart of many of our labs and detailed this on our internal wiki site.

wikitab

The idea was for part of it to be updated and maintained by our IT services and part of it by our department; we would make sure that PCs were in the correct position according to our own records for lab checks and that they were plugged into a corresponding wall socket. But this requires extensive user input and, predictably, will be prone to user errors. It was also pointed out to me at the time, when I borrowed the Fluke tester, that this collation of patch panel/switch port IDs had already been done by some interns and was now almost certainly already outdated. Nevertheless, I finished the mapping and maintained our side of things as changes were made.

And then changes were made that completely invalidated the entire chart.

Over the summer period in 2014, we had a network upgrade that saw the replacement of over 100 switches around the campus. Whilst no word to this effect had been made, it seems as though the switch configurations were probably from over a year ago – before any requested changes to the configuration had ever been made. With absolutely no communication about the upgrade or what might have happened, this presented a huge issue when upgrading our imaging system as it was slowly realised that there were a lot of small – with minimal overall impact – issues with the network configuration.

A new solution

It is clear by now that something more than just checking each PC individually needs to be done. This method is still viable for single sytems that might have the odd issue here or there, but to ensure 100% accuracy across all our systems there needs to be a different approach.

Wireshark provides a really cool piece of functionality that could help. Actually, this was what I have been using for about a year since I realised that it can be used to filter out LLDP and CDP packets after I noticed that the Fluke tester would pick up its information through these two types of packet (LLDP packets are broadcast every 30 seconds and CDP packets every minute across our network). The structure of these packets is very different (CDP uses an Ethernet frame and LLDP uses an Ethernet II frame) but both contain VLAN information, Switch information (for example IP, platform, version) and.. the switchport ID. This is accurate, it can be run on all PCs and we can get more information (VLAN ID, for example) than the Fluke tester would give us (I think it must be able to pull VLAN information out but I didn’t work out how to when I had a go with the one we used for a couple of weeks).

It is progress, but it was still intensive to do it this way, even with 4 or 5 people helping to go around a room. So can this be scripted?

If you strip out the GUI and just look at what Wireshark does, its functionally very similar to the Linux tool tcpdump which has a Windows port, WinDump (Actually, it is built using the same fundamental protocol – WinPCap, which itself is a port of libpcap). So in late 2014, I went about seeing what I could do to script WinDump and found through some quick googling that I could capture an LLDP packet or a CDP packet and then stop the capture after outputting the results of this one packet to a text file. This is great, although the formatting of the file isn’t particularly useful and would require some additional post-processing.

Windump curiously hasn’t implemented a nice formatting for LLDP packets and I would like to be able to utilise either CDP or LLDP outputs in a nice way – or really any network protocol. The only consistent way to output data is in the form of hexadecimal values. Both CDP or LLDP packets should output in the same format if the hex option is specified, but then what? There is still the issue to do with efficiency of data collection and obtaining the meaningful information – you still have to have somebody actually collect these results. The logical thing to do is to perhaps extend such a script to upload the output to a central server, but then I would have to process all of these text files and pick the useful information out.

So why not just do that processing on the PC before sending it? This is possible with a script, which could perhaps dissect an output text file – but with developing complexity, I decided that it could be a good idea to – instead – make a bespoke application that would actually grab all of this of data and upload only the useful parts that I want. Furthermore; rather than uploading a file, it would make sense to upload a record to a database that can store all of these results, foregoing any human interaction and even without needing WinDump at and only capture the relevant data we want in the first place.

So my work on this project, when time permits, has been to write a C (or C++) command-line application that utilises libpcap/winpcap – just as Win/TCPDump or Wireshark does – to capture either a CDP or LLDP packet and upload a string of text from that containing the switchport, vlan, hostname and IP address to a central database. So far it works quite well and hopefully will be releasing it for people to test out before making the source code freely available. I hope people can contribute to and help improve it and make it a genuinely useful tool for sysadmins across multiple platforms.

Edit: It could be suggested that I find out about connected hosts from the switches themselves or by using SNMP. The thing with various “switchport mappers” out there, however, is that they mostly seem to rely on using SNMP only. If you query a device that runs SNMP, you don’t necessarily get any more information than you would if you were to just look at that device yourself (for example, you can see all of a Cisco switch’s interface details to see host mac addresses; this is all you would receive back if you interrogated it with SNMP anyway).

What this program does, however, is a bit different. Whereas SNMP will give you a network map from the switch-side, this application will generate more detailed host information from the client-side. Switches won’t know a host’s IP address in all likelihood and certainly not hostname or any other information that you might want. Although you can find most of this out with other applications, this program will combine its own information with that given to it by a switch.

Of course, having the SNMP-derived information about a switch actually is not un-useful; this way, you can see every device that is connected to a switch, whereas what I have developed will only show you the information about hosts that you have run this application on (or that you can have remote access to, or have imaged with it already on and scheduled). It is quite possible in an environment such as the one that I work in that you can have other devices that you don’t have access to (AV and Wifi access points for example) and so you can’t make assumptions about free space on switches. So for the future, perhaps some SNMP integration with this application would make it a step beyond what most switchport mappers would normally provide (without being overly complicated). I guess this could help direct what the name should be, a bit more..

Tuesday, January 24, 2012

Five app trends to look out for in 2012

Five app trends to look out for in 2012Every day consumers from all over the world download millions of apps from an increasing number of connected devices, including laptops, tablets, e-readers, smart TVs and smartphones. Today most app publishers are finding themselves in a similar position: They’ve made the decision whether to make apps native for each operating system or use HTML5 to construct a web app, and they know which app distribution channels they’ll be using. While their current biggest challenge may be how to keep up with existing demand, it’s of great importance to look a bit further ahead as well. Having a strategy in place designed specifically with future trends in mind is key for ensuring continued distribution and revenue success.

Over the past few years app developers, publishers, and stores around the globe have seen the industry evolve in response to a defining trend that has affected tech consumption across the board: consumer empowerment and choice. Customers hold the power to review an app positively or negatively and they have options for obtaining content through their desired app stores – and that’s just the way they like it. For example, a user with an Android device can download or view content from their choice of app stores, including Android Market, their mobile network’s app store, or other sources like getjar.com.  Even “out of the box” Apple device users have the option to consume apps through Apple’s App Store or via an HTML5 app the shopper navigates to through their Safari browser.

So in a global market where the connected customer rules, here are some 2012 trends publishers and developers will need to consider to make sure their apps remain in high demand, are available where and when customers want them, and are as profitable as possible.

1. App monetisation

App monetisation is the ability to create a consistently productive revenue stream from an app after it is in the hands of your consumers. As app publishers have gained their footing in the various app distribution channels, and as they continue to better understand the terms and conditions of the agreements for app stores, I expect monetisation to become their next logical area of focus and for good reason: today, 65 per cent of “freemium” games revenue comes from in-app purchases as does 72 per cent of Apple’s app revenue. So publishers with a solid monetisation program will be the ones best poised to dominate the market in 2012.

The first step in monetisation begins by understanding the current lifetime value of your app user base. Next, find ways to consistently make that value go higher. Monetisation tactics that can increase customer lifetime value include in-app advertising from house ads or an ad network, in-app incentive based advertising, in-app advertising promoting the distribution of other app publishers’ apps, and in-app purchases selling incremental products and services.
An example of an app monetisation program where a non-incentivised in-app ad promotes another app
An example of an app monetisation program where a non-incentivised in-app ad promotes another app

2. Security

Recent press about cyber attacks has made the connected customer more security savvy.  For example, most iPhone users don’t want to “jailbreak” or otherwise modify their device because they believe it could increase their threat exposure. They assume that single sign-on and social sign-on provides greater security. The bottom line is that users expect their online experience to be as secure as possible.

In this environment, and as the sophistication of apps continues to increase, the responsibility lies with app publishers to meet these high expectations by making sure their product is secure and protected from malicious apps that may be on a user’s device. With data on the line that can include credit card, banking and valuable personally identifiable information, the stakes are high, but the reward for trusted app publishers is significant. Deliver a secure experience for your user and they’ll show their appreciation through increased willingness to interact and transact within apps.

3. Targeting and personalisation

App publishers are gaining a better understanding of their users and 2012 is the year we should begin to see leaders pull ahead of the pack by leveraging that understanding to target their efforts and personalise the user experience. One top trend will include targeting the placement of specific apps to specific app stores based on user behaviour and preference.  This approach is similar to one often taken with search engine marketing.
Let’ s say you make widgets and you’re advertising on Google since that’s where you’ll see the highest search volume on most of your keyword phrases. However, your widget may appeal greatly to a niche consumer who only always visits another search engine. In that case, you must create campaigns geared toward the particular customer that run on their preferred search engine.
The same holds true for app stores, as well. Identify which stores produce higher revenues or lifetime value metrics for a particular type of customer. Target your distribution accordingly and personalise your approach for each of your highest performing stores.

Another opportunity for 2012 is personalised app content. As proliferation of HTML5 and hybrid apps (a combination of a native app and a web-based app) continues, and as users become more comfortable receiving personalised content as part of their website browsing experience generally speaking, they will expect their in-app user experience to be personalised, as well.  Examples include targeted in-app advertising and targeted services leading to in-app purchases.

4. HTML5

Some may be skeptical of HTML5, seeing it as just a passing fad. However, publishers and developers should care about HTML5 because an HTML5 app can free them from paying the app stores 30 percent for their customer’s initial app purchase or for in-app purchases.

For example, Apple’s completely closed ecosystem doesn’t allow any app that hasn’t been delivered through Apple’s App Store to be installed on an Apple device unless the device happens to be jailbroken. This requires the app publisher to pay Apple 30 per cent for all transactions that occur through the app store, in app purchases, subscription billing, and so on. But by deploying an HTML5 app, the Apple user can navigate to the HTML5 app via their Safari browser and download the app to their device. It really isn’t a download per se – technically, it's a bookmark – but it looks and feels like a typical app that would be placed on the desktop of the device.

However, HTML5 apps are not without their challenges, one of which is visibility. HTML5 app publishers can’t count on an app store for exposure, so different tactics are required to achieve large scale distribution. Additionally, there are HTML5 app stores that I believe will garner more attention from end users. This may help further address visibility and distribution challenges.

5. In-App analytics    

As the app market matures and the connected customer exercises their power of choice, user retention and engagement may become one of the app publisher’s largest challenges in 2012. Analytics can help customers keep an app longer and stay engaged with it. This can reduce acquisition costs and increase customer lifetime value.

Why? Because more leading app publishers will be monetising the user throughout their lifecycle, acquiring their customers through app store targeting, and personalising in-app content. In-app analytics is the critical component that will enable each of these trends to be repeatable, reliable revenue drivers. Website analytics are now the de facto standard for providing actionable insight on web behavior and, since apps are now the online store for the app publisher, the same insight will be required for apps. Yes, you read that correctly: the in-app experience will increasingly function as the online store for the app publisher. Leaders in this space will come to rely on in-app analytics for full optimisation of the user experience and monetisation of the app lifecycle.
An example of an advertisement promoting wedding DJs that is served because the words “Wedding Chapel” appear on this album cover. Expect to see better targeting and personalisation in 2012 as in-app analytics improve
An example of an advertisement promoting wedding DJs that is served because the words “Wedding Chapel” appear on this album cover. Expect to see better targeting and personalisation in 2012 as in-app analytics improve
The 2012 trends for app publishers are fast moving – more may emerge yet this year – and while it may seem difficult to keep up with current demands while also looking  to the future, it’s important to keep in mind that most of what happens in the industry will likely continue to be driven by the connected customer. Keeping users top of mind will serve every app developer well in a wide variety of market conditions.

Wednesday, January 18, 2012

Share your open source project via GitHub

Share your open source project via GitHub

As GitHub brings the power of social networks to the open source coding community, this article explains how to successfully interact with it

When many people hear Git, they think GitHub. GitHub is the popular online Git hosting service that has brought the power of social networks to the open source coding community. And as more and more projects switch to Git and an increasing number of companies and individual developers move there to host their open and closed source projects, it’s becoming ever more important to know how to participate in that community.
GitHub has over 650,000 developers registered on the site, hosting more than 500,000 unique open source projects and 1.8million total repositories. Companies such as Twitter, Facebook, Yahoo and Rackspace, among thousands of others, use GitHub to share their open source projects and take contributions from the larger open source community. Many more companies use GitHub to outsource their code hosting needs or find developers to hire – learning the site may be how you get your next job or what you use when you get there.and today we’ll look at using GitHub. We’ll see how to create an account, add an existing project to Git and push it to GitHub to share with the wider community. Finally we’ll learn how to contribute to someone else's open source project on GitHub. By the end of this tutorial, you should feel comfortable open sourcing new projects on GitHub as well as contributing to existing projects that you discover on GitHub.

1. Download Tower

If you don't yet use Git, you can download the free command line client at git-scm.com, or you can get one of the GUIs. Here we'll use Tower, a commercial Mac GUI client with a 30-day trial that you can download from git-tower.com.

 2. Import and commit code

Download the files from above. Unzip the file and initialise the directory as a Git repository. In Tower, click Create Local Repository then select your path. You can then do your first commit by clicking Stage All and then the Commit button.

 3. Create an account

Our first goal will be to push this code up to GitHub to share with people. To do this, create an account on GitHub if you don’t yet have one. Go to GitHub.com/plans and click on the Create a Free Account button then fill out the simple form.

4.  Create a new repository

To share your project, we need to create a repository on GitHub. You should see a button titled New Repository on the dashboard you land on after creating an account. Click on it and provide a project name in the next form to create your new repository.

 5. Add GitHub as a remote repo

In Tower, select Refs > Add New Remote Repository and paste the HTML URL found on the project page into the URL box on the form that comes up. Then type in your GitHub password and click OK.

 6. Push your code to GitHub

In Tower, right-click on the master branch in the sidebar and select Publish Branch. This pushes your work to GitHub, so you can go to your project page and see your published work. From now on you can just click Push to share further updates.

 7. Fork a repository

We have shared some code, so now we should contribute to a project. The first step to working on a project in GitHub is to fork it, ie get your own writeable copy. Go to GitHub.com/schacon/example and click the Fork button to achieve this.

 8. Clone that repository

In order to improve this project, we’ll need to get a copy locally to edit. Select the HTTP URL from the project page and tell Tower to clone it for us. Go to the Repositories page (command+D), click on Clone Remote Repository and paste in the HTTP URL.

 9. Make a change

Now we want to add a feature, so we should create a branch to do the changes in. Create a new branch (command+B) named new_feature and check it out. Then copy the two files from the original example project into this forked repository and commit the new changes.

 10. Publish your topic branch

Right-click on the new_feature branch in the sidebar and select Publish Branch to publish it to GitHub. This will create a new branch named new_feature on GitHub that the original author of the code you forked can now see with all your new work.

 11. Start a pull request

Since our work is now public and on GitHub, we want to tell the original project author to incorporate it into their project. This is called a pull request. Go to the forked project page
and click the Pull Request button to open the form.

 12. Fill in and inspect your pull request

Fill in a convincing title and description of why your work should be incorporated. In the Commits tab you can see the list of unique commits you're sending. In the Files Changed tab you can see the unified diff of what you're sending.

 13. See image differences

When an image is modified, GitHub enables you to use multiple views such as side-by-side, swipe, onion skin and difference so you can see how it was changed. Once you are happy with the change, go ahead and send the Pull Request.

14. Comment on changed line

Pull requests act as a code review process, and GitHub lets you have a conversation about the changes before they are accepted. Go to the Files Changed view of the request you just sent and comment on a line of code.

 15. View pull request discussion

Once you've commented, you can see the comment and all other related information for the pull request on the main pull request page. Click on the Discussion tab to see how your comment and code context is now in the main discussion list.

 16. View branch list

Now that you have more than one branch pushed to your project, you can compare them with the Branch List view. If you click on Branch List under the Source tab you get a nice visualisation of all your branches and how many commits are unique to each.

 17. See compare page

If you’re interested in one of the branches and want to see how it compares to your main branch, click the Compare button on the Branch List page next to that branch. This will bring up a view of your changed files, a unified diff and a list of commits.

 18. Your pull requests

To keep track of the status of your sent and pending pull requests for projects you have on GitHub, you can click on the Pull Requests tab from your Dashboard. Now that you’re participating in a social coding network this is important.

 19. Your profile

Now that you’re an active and trained member of the GitHub community, make sure you’re represented properly. Your profile page, found at GitHub.com/[username], is how people can see who you are and contact you. Be sure to upload an avatar at Gravatar.com and fill out your profile.
Expert tip: The GitHub user interface is very nice, but if you need to do something different or repetitively, GitHub also has a lovely little API that enables you to do with a script just about anything you can do through the web user interface. Visit develop.GitHub.com to learn more about how to script any of your GitHub interaction, including existing libraries to make it easy to do so in Java, JavaScript, PHP, Perl, Python, Ruby and more. If GitHub doesn't do exactly what you want, it's possible that you can bend it to your will.

Preparing an application for distribution

Preparing an application for distribution
  • Knowledge needed: Objective-C, way around iTunes Connect, Xcode, Cocoa, iOS development
  • Requires: An iOS app, Xcode, Apple Developer Account (Paid iOS Developer)
  • Project time: 1 hour to set up beta team and 1 month for beta testing process

Creating an application can be extremely exciting for any developer but before you get your application published, you need to get it ready.

Getting an application on the App Store is an exciting moment in any developer’s career although despite the excitement – distributing your application to the App Store and to beta testers can pose somewhat confusing problems for even the most experienced developer – this article aims to point the budding App Store entrepreneur in the right direction to conquer both the Mac App Store and the iOS App Store.

Beta testing

The first thing one should consider – before even thinking about selling an application on any medium – is beta testing.
In my own experience, the hardest part of the whole beta process is actually ‘hiring’ people to test your app. I can guarantee that only about 40 per cent of the people you ‘hire’ will actually provide good, in-depth and useful feedback on your app for every beta release you push out. I have found that the best way to get people to beta test is to create a simple contact form on a website that you can quickly redirect people to (for example, website.com/beta). Ok, but how do I actually get traffic to my beta website? My simple answer to that would be: post about it – market it on forums and social networks. After that, there’s two main routes to take...
  • Beta Testing Option 1: Simple ad-hoc distribution. This option is possibly the least efficient of the two. Ad-hoc distribution is good if all you want is communication via email and don’t want anything too fancy. This option includes you simply creating a Provisioning Profile in the iOS Dev Center and adding your beta tester’s device UDIDs to it and then simply Archiving your application with the Distribution certificate and sending out the .ipa application via email and relying your testers to get back to you with screenshots, crash logs, feedback and comments manually. As I said, only about 40 per cent of all of your testers will get back to you with good, decent comments. Furthermore, with this method, testers then have to sync their provisioned devices with iTunes and sync the application as if it were any ordinary application.
Archiving your application within Xcode for App Store submission
Archiving your application within Xcode for App Store submission
  • Beta Testing Option 2: Using a third-party beta service. There are many services that allow you to up your IPA and have a testing team and these services usually allow you to see how people are using your application and what options their taking.
When beta testing I have learnt many lessons. I have learnt that even if you have hundreds of beta testers one of which is that no-one else using your application looks at it the same as you do – it’s like that old cliché: no-one cares about you, as much as you do – this is the same for your apps. I have also learnt that beta testing takes time and you shouldn’t anticipate a both reliable and accurate beta testing program if you want to be done with the testing within one week, regardless of the size and complexity of your application. What’s more, I have learnt that, during testing, your beta testers are the most important people in the world – you need to thank them for their ideas and comments constantly as they can potentially stop your application from going into the App Store and simply crashing and burning.
Right, the timely process of beta testing is done, now you need to submit your application. To start this process, you need to head over to itunesconnect.apple.com/ and select Manage Your Applications and then select the Add New App and follow the relevant steps to adding your application to iTC.
The main part of iTunes Connect where you manage your applications
The main part of iTunes Connect where you manage your applications
The screen within iTunes Connect when you’re adding a new application
The screen within iTunes Connect when you’re adding a new application
Adding a name to your application within iTunes Connect
Adding a name to your application within iTunes Connect
Once you’ve done this you now need to upload your application. You do this by changing your application to Ready to Binary Upload and then Archiving your app in Xcode and submitting it via the Organizer.
The Archives tab of the organizer
The Archives tab of the organizer
Now, this is where it gets really interesting. The only hurdle between you and App Store domination is Apple’s app review team and Apple’s app review process.
An application in review with the App Store review team
An application in review with the App Store review team
Once you’ve submitted your application to the App Store, you’ll find that for the majority of the time prior to your App Store release, your application state is Waiting for Review.
A small side-note, accordingly to some statistics released not that long ago by Apple, 95 per cent of new apps are fully reviewed within seven days and 98 per cent of application updates are reviewed within seven days so you should expect your application to be reviewed within seven days – that is, of course, you’re not part of the unlucky 5 per cent.
Interesting stats about the app review process
Interesting stats about the app review process
After a couple of days have elapsed, you’ll find that the state of your application changes to In Review – this is where all of your hard-work can truly pay off; on the other hand, this is where all of your hard-work can quickly become a waste of time. In the past, I have had an application rejected within one hour and I have had an application in the In Review state for about four days. In fact, I have an application right now that’s been in review for around three days.
If all doesn’t go to plan and your application, sadly, gets rejected, then the kind folks that rejected your hard-work provide a very in-depth description as to why your application was rejected as well as any crash logs and anything you should do to get your application accepted next time. Furthermore, if you’re completely stumped as to how to correct a specific problem, you can take advantage of your two free iTunes Technical Support requests – every developer gets two free support requests and Apple gives you a very qualified expert that will help you out with your problem!
However, if all does go well and your application does indeed get approved, you’ll find that the state of your application goes from In Review to Processing for App Store and then at last, Ready for Sale! That is, of course, providing you have all of your contracts in order – you will have to have all of your contracts in order if you want to get an application on the App Store – even if your application is free, you’ll need a contract in standing-order and you should also have all of your metadata is good, standing order because your application will get rejected if it’s not correct.
Having an app on the App Store does give the you, the developer, a great feeling! You’ve gone from putting your passion and boxing it into an app to be successfully approved by a notoriously frustrating app review team.
However, just because you’ve got an application on the App Store doesn’t mean you can stop worrying about the app. If you want to get good ratings and feedback, then you need to listen to your customers. I mean, these people have given you their money – the least you can do for them is listen to them.
I try to push out a ground-breaking new feature in my apps every month or two and I ensure that every two weeks I release a minor update, nothing I create is never truly finished and I always ensure that the apps I create are these living, breathing entities that people enjoy to use. So go ahead and create something amazing and go the extra mile to make each and every one of your customers go “wow”.

 

Saturday, December 3, 2011

A comparison between sIFR, Cufon and @font-face

Every now and again we at Solid State like to review the current trends in dynamic text replacement techniques; getting text on a web-page in a non 'web safe' font.
Traditionally, 4 years ago, if you really, really needed to use a particular non web-safe font, you would have had to use an image instead, alongside a CSS technique like one of these.  This is an approach that is still widely used due to the fact that it's easy, SEO friendly and relatively fast to render, providing you use CSS sprites.
For static web sites this worked well, up until the text needed changing, creating the tiresome process of starting Photoshop whenever a website required an edit, creating the new heading, uploading it and proofing it. A content management system vendor, such as ourselves, is always on the lookout for a better solution.

The three options below represent the current state of the art. Unfortunately none of them are clear winners in terms of overall functionality. Like most things in web development, it's a compromise; chose the right tool for the task in hand.

sIFR

Back in around 2005, sIFR appeared, and everybody thought it was going to change everything. It did, sort of. Beautiful, SEO friendly, dynamic text was now possible, but it was slow to render on the page, created complications using AJAX, and despite what the documentation suggested, was a nightmare to implement with links and navigational elements. Oh - and Flash was required too. And so it is for these reasons why most web-developers wince slightly whenever the technique is mentioned. In fact, even though the 3rd version of SIFR is a little better than its original incarnation, I'm grimacing a little as I write this...

Cufon

In an attempt to tackle sIFR's shortcomings, a clever guy called Simo Kinnunen came up with Cufon - a JavaScript rendering engine that made use of VML in Internet Explorer, and the HTML5 <canvas> element in other browsers, to render custom fonts. It doesn't need Flash, it's faster to render than sIFR and from what I can see from it's demos page, it's suitable for navigation too.  My colleague Paul (@paulmasek), has just started a project using it, so I'm sure we'll be talking about it soon. Watch this space.
The main drawback with Cufon is that you can't select the rendered text as you can in sIFR. If the user wants to select it in order to copy it somewhere else, they are going to end up confused.  Interestingly, it is worth mentioning Typeface.js, which works in a similar manner to Cufon. If you are happy to sacrifice a little rendering performance, it is possible to select the text rendered with Typeface, though it has to be said it did work quite slowly when we tested it.

@font-face

Whilst these techniques are great in providing credible solutions to the lack of available fonts to web designers, it does suggest that there should be a better solution; one that wouldn't require messing around with JavaScript and Flash. After all, other fonts can be specified in the regular CSS 'font-family' property, but there is no guarantee of their installation on users' computers.
@font-face is a css technique that has actually been around for a while; it was first defined in the CSS 2.1 specification. It allows a font to be hosted on a web server and referenced within a web page, creating the 'perfect' solution to this issue.
Well, almost! Apart from the thorny issue of font that needs to be dealt with, together with increased page loading times due to the download of the font file itself, there is something of a show stopper to this technique.
Unsurprising, it's Internet Explorer that causes us the grief. Not that IE doesn't support this CSS property - in fact IE4 was the first browser to do so back in the dark ages. But to this day it only supports @font-face using an Embedded Open Type (.eot) font, which would be fine, but for the fact that creating one of these involves the most unnecessary and laborious process using Microsoft's WEFT tool, which is where most people give up. And to be honest, so did we.

And the winner is...

So, to summarize:
 Images with text replacementsIFRCufon@font-face
Dynamic TextNoYesYesYes
Browser compatibilityAll modern browsers, inc IE6All modern browsers, inc IE6All modern browsers, inc IE6Limited support in IE
Needs pluginNoYes (Flash)NoNo
Rendering speedFastSlowFastFast
Selectable textNoYesNoYes
Relative ease of implementationEasyDifficultSo-soEasy
Suitable for hyperlinksYesEventuallyYesYes
My opinion remains that we should still try and use web safe fonts, certainly for main text blocks. For static headings (for example sidebars and panels) I still think CSS image text replacement, cunningly crafted with CSS sprites, is still the optimum technique, especially in a world where JavaScript heavy sites are becoming more common. In instances where we do need dynamic text, providing it's using sparingly I'm tempted to go with Cufon; it is relatively easy to implement and has provided us with some good results so far.
I would love to say otherwise, but regardless of the hype that @font-face seems to be generating at the moment, I can't see it's widespread adoption happening any time soon. Microsoft still needs to resolve the font DRM issue, so it can allow more common font types. It might seem a while off, but together with every other web developer out there, I can't wait for that day to arrive!

Tuesday, November 22, 2011

10 Usability Nightmares You Should Be Aware Of

Sometimes you just want to get the information you’re after, save it and move along. And you can’t. Usability nightmares — which are rather the daily routine than an exception — appear every now and again; usually almost every time you type your search keywords in Google. In his article “Why award-winning websites are so awful” Gerry McGovern points out that “the shiny surface wins awards, real substance wins customers” and that is absolutely true.
Nevermind what design you have, and nevermind which functionality you have to offer — if your visitors don’t understand how they can get from point A to point B they won’t use your site. In almost every professional design (except from special design showcases such as, e.g., portfolios) you need to offer your visitors
  • a clear, self-explanatory navigation,
  • precise text-presentation,
  • search functionality and
  • visible and thought-out site structure.
And that means that you simply have to folow the basic rules of usability and common sense. You want to communicate with your visitors, don’t drive them away, right?
In this article we take a look at some of the usability nightmares you should avoid designing functional and usable web-sites. At the end of the article you’ll also find 8 usability check-points you should probably be aware of.

1. Hidden log-in link.

Backpack, 37signal’s one of the most usable organizational and project management tools out there, explains exactly what the tool can be used for, how one can use it and which features it has to offer. However, once you’ve signed up, you might need few minutes to find out what you should do to actually start using the tool.
Backpack Login
The “Log in”-link (hint: in the yellow box) should have a greater font-size — also icons would do the job. Every registered user has his/her own personalized page, however new registered users will need a while to find out how they can log in. As Lee in our comments said, “someone thats invested their time to sign up for a service will spend more than two seconds finding out how to log in.” Ok, but why should he/she? Why not just place the link somewhere where it’s visible? It sounds reasonable to us.

2. Pop-ups for content presentation.

Almost every modern web browser uses a popup-blocker to prevent pop-ups, ad blocks and further site content recognized as advertisement. Firefox, Safari, Opera and Internet Explorer make use of it — therefore the idea to use pop-ups to present the main content isn’t probably the most reasonable idea web-designer might come up with.
Adidas Pop-Ups
However, Adidas developers team seem to consider pop-ups as a creative approach for their target audience. It’s not clear what ImpossibleStory.com is actually about — most users will never find out; even we were too lazy to deactivate our popup-blocker.

3. Dragging instead of vertical navigation.

Actually, this technique — not a real nightmare, but very unusual — might become a new trend in the future. Dragging, as used from .pdf-documents, can also be adapted to web-sites. Fichey offers a Flash-based solution. Interesting approach, however you can’t bookmark specific parts of the site – a typical problem for Flash-based designs.
Fichey
An introductory info box on the start page of the site informs its visitors about the new way of navigation. The tool shows sites which are currently popular in social media. By the way, the displayed links don’t work – apparently, the tool shows the screenshots which are saved and embedded as images.

4. Invisible links.

Visitors have to know where they are, where they’ve been and where they can go next. If designers don’t present this information in an appropriate way, visitors can have serious problems with site navigation. Real Player had been using a bunch of invisible links for a while. Take a look at the picture and the labels below (originally created by Trenton Moss) — can you spot the links?
Real Player
1, 3, 4, 6, 7 and 11 are links, and 2, 5, 8, 9 and 10 aren’t.

5. Visual noise.

Often less is more. Visual noise is probably one of the most typical problems large web-sites’ designers have to cope with. And it’s extremely easy to get it wrong. As Overstock does.
Overstock
Bonus: It’s also not quite clear what is a link and what’s not. Overstock also uses a number of different link presentations and hover effects. Link or not a link? You might have a lot of fun finding out.

6. Dead end.

You can use different approaches to introduce your new web-service to your visitors. Scriblink welcomes its visitors with a pop-up and a Java-applet. Visitors have to provide some input to start browsing through the site.
Scriblink
Nothing helps:
  • clicking on “cancel” doesn’t help,
  • OK doesn’t help,
  • full-screen mode doesn’t help,
  • clicking somewhere else doesn’t help,
  • closing the browser window doesn’t work,
  • clicking on the question mark for help doesn’t work.
Unfair, really. We just wanted to see what the tool does…

7. Content blocks layering upon each other.

A typical problem which always appears if large Flash-movies are used on large web-sites. The site navigation is hidden; whatever users might be willing to browse to — they have no chance.
Photoimpact
The same problem on Yahoo.com:
Yahoo

8. Dynamic navigation.

What looks like a usable site navigation, shows itself soon enough from its worst side. Nevermind where you point your mouse pointer to — supporting images slide down and up and change the focus of the link you’ve clicked on. On the image below the link “history” was clicked – it moves away; and no, the sliding images aren’t linked to the page you’d like to browse to.
Brown University
The effect appears in both left- and right-side navigation menus. Visitors might need some time to find out what is happening. However, once the idea is understood, the navigation isn’t that hard to deal with.
Kabe243
The same idea on Kabe243. Bonus: visual noise at its best.

9. Drop-Down Menus.

Drop-Down menus are useful for web-developers and almost always get on users’ nerves. If you — as a designer — hide navigation items in a drop-down menu you can save yourself a large amount of vertical space; however users have to focus the mouse precisely to get to the section they’d like to visit. It’s not usable.
However, it can be even worse. If the distance between different levels of navigation is too large (for instance because some navigation items have more text) users have to move the mouse horizontally. If the mouse focus changes its vertical position, users have to start from the beginning.
2Advanced and Brita.net are excellent examples for these usability nightmares.
2Advanced
Brita
Notice: it took us a dozen of attempts to actually make these screenshots.

10. Blinking images.

Sometimes you just want to read the content of a web-site you are visiting. And you can’t. To fight against the banner blindness advertisers make use of animated ads — usually animated .gif-images or Flash-movies. In both cases it might become extremely hard to focus on reading if such images are blinking all around the content.
Digital Web Magazine, an excellent online magazine we read on a regular basis, has a disturbing animated ad on the left side of every article.
Digital Web

Future Nightmare?
Pointing the mouse instead of clicking.

Dontclick.it, an interesting experiment in interaction design, explores a clickfree environment. It wants to explore how and what changes for the user and the interface once you can’t rely on the habit of clicking.
Dontclickit
Within this interface you won’t find any buttons. Instead you navigate the contents in a different way — by pointing the mouse to the areas of the site you are interested in. What sounds like an interesting approach might soon become a usability nightmare – just imagine web-users trying to open external links in a new browser window; besides it’s interesting to know how exactly users will be able to, let’s say, open a list of links in new browser tabs (updated to clarify why we’ve put Dontclick.it in this post).

8 Usability Check-Points You Should Be Aware Of

  1. You don’t use pop-ups.
    Pop-ups interrupt the browsing session of the visitors and require an instant feedback. Respect your visitors.
  2. You don’t change users’ window size.
    The same argument as the one against pop-ups holds. Some browsers, e.g. Internet Explorer, saves the browser dimensions and uses them for further browser sessions. As Ben Bodien commented, “it’s just plain inconsiderate to assume that you know better than the user how their software environment should be configured?”
  3. You don’t use too small font sizes.
    Long passages are harder to read, and to read brief sentences readers need more time. It holds also for links, buttons, forms, search boxes and other elements. Good news — in Web 2.0 the opposite is the case.
  4. You don’t have unclear link text.
    Links have to be precise and lead to the destination they describe. Ambiguous link descriptions should be avoided.
  5. You don’t have dead links.
    There are too many of them anyway; why would you want to point your visitors to a dead end?
  6. You have at most one animation per page.
    If blinking images are wide-spread through the site, it’s extremely hard to focus on one single site element. Give your visitors an opportunity to perceive your content. Using animated ads, don’t place them right along your articles.
  7. You make it easy to contact you.
    Maybe because you just don’t want to be contacted, but If visitors do want to get in touch with you, but can’t find any contact information, you lose their interest and trust. Disastrous for online-shopping, a missed opportunity for the rest.
  8. Your links open in the same window.
    Visitors want to have control over everything what happens in their browser. If they’d like to open a link in a new window they will. If they don’t want to, they won’t. If your links open in a new window you make the decision which is not your decision to make.

Saturday, October 22, 2011

How Drupal CMS stands above the rest


As a site developer, web designer or site administrator, you’ve probably had to go through the process of choosing between platforms. But maybe not recently—if you’ve been designing and developing web sites for very long, chances are you’ve already got your favorite go-to platform that you always use. And if your go-to content management system isn’t already Drupal, maybe it’s time to take another look.
The downside is, Drupal is huge. There is a steep learning curve and it can be a full-time job just looking through all the contributed modules to find exactly what you’re looking for. It is not a happy-go-lucky, “set it up right out of the box” platform.
But the upside to all of this is, Drupal is huge! There is nothing you can’t do with Drupal. Want to run a blog? Done. Want to run a blogging community? Done. Share links and photos, run classified ads, show Twitter updates and statuses, sell products, upload and share files, play movies, even manage a wiki? Done, done, done, done and done!
At the risk of sounding trite (and please forgive this slightly over-used phrase)…Drupal is as Drupal does…And Drupal does it all. So what makes Drupal stand out so much? Many things, but we’re going to focus on just the most important aspects right now..


19 Sep



As a site developer, web designer or site administrator, you’ve probably had to go through the process of choosing between platforms. But maybe not recently—if you’ve been designing and developing web sites for very long, chances are you’ve already got your favorite go-to platform that you always use. And if your go-to content management system isn’t already Drupal, maybe it’s time to take another look.
The downside is, Drupal is huge. There is a steep learning curve and it can be a full-time job just looking through all the contributed modules to find exactly what you’re looking for. It is not a happy-go-lucky, “set it up right out of the box” platform.But the upside to all of this is, Drupal is huge! There is nothing you can’t do with Drupal. Want to run a blog? Done. Want to run a blogging community? Done. Share links and photos, run classified ads, show Twitter updates and statuses, sell products, upload and share files, play movies, even manage a wiki? Done, done, done, done and done!
At the risk of sounding trite (and please forgive this slightly over-used phrase)…Drupal is as Drupal does…And Drupal does it all. So what makes Drupal stand out so much? Many things, but we’re going to focus on just the most important aspects right now..
WordPress Themes

Views

First… Views. I could almost just stop right here. No other platform offers your site the power and flexibility that Drupal does through Views.

For those of you not already well-versed with Views and all its glory, let me explain it to you. In a nutshell, Views allows you the chance to define how you want the content on your site to be displayed. But that’s not all. Thanks to the powers that be at the Views project, Views allows you to query your Drupal database for the content and define and solidify exactly how you would like to display the content retrieved from the query… all without having to write the SQL queries yourself. And with the even more simplified administrative interface offered by Drupal 7, building Views has now become streamlined. A basic View – say, showing a list of all the products on your site – can be set up, configured, and saved in two or three minutes.
More complicated Views will take a little longer to set up and configure—for example, maybe 15 minutes to set up a list of all your members as an exposed proximity search by zipcode.

If I never have to write another SQL query, I will die a happy web designer! Even if you love SQL, who wants to spend unnecessary time on repetitive tasks? Views helps you stay focused on the important parts of your project.

Custom Content Types

Next, Custom Content Types. The Content Construction Kit (CCK) has been around for, well, forever. CCK was a contributed Module for Drupal 4, 5 and 6, but now with Drupal 7 most of CCK has been added to Drupal Core.
The Content Construction Kit does, pretty much, what it says in its name—it’s a kit to help you construct various types of content. Thanks to CCK, you can have thirty different types of content and each one can be glorious and different from all the others. For example, you can have real estate listings in which there are fields to input things like square footage and the number of bedrooms. Or you can have auto listings that need a whole separate set of fields. Here’s an example of various content types in action:

It just doesn’t get much more flexible or easy than this.

Powerful SEO Tools

Third, Search Engine Optimization galore! It would probably take me ten articles to describe to you the top ten ways that Drupal rocks SEO…and even then I couldn’t get into any real detail or address every aspect of the power behind Drupal’s SEO capabilities.
Everyone knows about how important it is to optimize content for SEO, and add in things like keywords and meta tags. And Drupal gives you the power to do this. But Drupal goes even further by offering you full control over your URL structures, page titles, and even power over caching tools.
Plus, integration with other SEO tools such as Google Analytics is easy to do and highly configurable. Want to track your members but not your moderators? It can be done! All from within Drupal, all without manual programming… And all for free.
I have two words for this…Rock On. By radically simplifying this side of things, Drupal helps increase the value of the services you can provide to your clients – all in a pain-free way.

Versatile Theming System

Fourth, Drupal’s theming system is extremely versatile – and perfect no matter your level of experience.
For new users, Drupal offers a slew of free themes that are ready for you to use right out of the box. And we aren’t talking about bottom-of-the-barrel themes that will make your site look like it’s been built with a free theme. We’re talking beautiful, professional themes that will give your site a clean, professional look without much work from you at all. Check out these examples:
Changing the look of your Drupal site is as easy as uploading your theme to your server, and clicking on a link in your site’s theme administration system:

For more experienced users looking for an option somewhere between building a custom theme and using one of the available free themes, Drupal also offers a collection of starter themes that will provide you the basic building blocks—allowing you to further customize and build your theme on top:
And for you experts out there, Drupal has provided you with a thorough explanation of their theming system, including basic page templates, hooks, functions and classes.
Taxonomy and Unicorns (well, maybe)
Fifth is the magic of taxonomy. Okay, so taxonomy isn’t actually magical (it’s the science of classification)—but it might as well be. Through Drupal’s taxonomy system, you can build a seemingly limitless hierarchy of keyword-rich terms that will help you classify and categorize your content.
From there, you can even build menus, pages, and Views that center on this taxonomy. Each Vocabulary on your Drupal site can be as strict (select a term from the given list) or as free (type in a term) as you like. Powerful organization and easy management is magical, right?

User Management and E-Commerce

Next is the sheer power and flexibility offered by Drupal’s user management capabilities. You have absolute control over everything, including registration, member profiles, content access controls and role assignments. You can allow or restrict inter-member communications as much or as little as you like – from full-blown community sharing to simple forum discussions or messaging.
Let’s not forget e-commerce…Drupal has several options available for your e-commerce site, including the ever-popular Ubercart and, of course, the creatively-named Ecommerce.
Create and control inventory, offer shipping quotes, calculate taxes and handling fees, accept payments from any of several payment gateways…The sky is truly the limit. No need to find a third-party resource to list and sell your products; it can all be done from within your site.

Awesome Community

And finally, Drupal’s awesome community of developers, themers, programmers and overall support sets this content management system apart.
First, the centralized repository for Drupal modules helps ensure that the support queues and version control are handled in a more universal way and remain GPL compliant. (Don’t know what GPL compliance means? Basically, it means you won’t have lawyers breathing down your neck!) If you happen to be a developer of one of the many (many, many…many) contributed modules on Drupal, you can be assured that your module will get a high level of exposure and be thoroughly vetted by the Drupal community.
And, Drupal has been around a long time—which is a huge benefit for a number of reasons. It’s stable and it works; its longevity already proves that. But, let’s be honest: other CMS platforms can boast the same thing. But can everyone else also boast that they have never forked or branched out? The Drupal community works together: programmers work in hand with writers to bring you the documentation area, guides, and handbooks; developers of one module work together with the developers of other modules to help design better integration. And they do it in such a way that allows your online presence to continually grow and expand without ever having to hack into the core modules. And who wants to hack into the core of anything?
While we’re on the topic of community and universal handling of modules, I should note how easy it is to hand off a Drupal-based project, or get a new developer on a project up to speed. I know… as a business owner you would never have to fire your existing site developer and, likewise, as a site developer you would never leave your client. You are both mutually awesome and work together perfectly.
But, in the chance that I am wrong and you do find yourself someday in a predicament where you’re looking for someone to continue the work for a site being developed, almost anyone trained in Drupal can handle that for you without worry. There’s no need to feel like you’re stuck with a platform that no one else can learn or understand. Also, if your project takes off and you need more help, you can get a new developer going in almost no time.

Conclusion

In short, if you’re looking to build a simple site with anywhere from six to twelve pages that aren’t going to be updated all that frequently, then Drupal is probably over-kill. But if you’re looking to build a robust site with infinite possibilities for expansion and growth, Drupal is an absolute must.
If you’re a brand-new beginner within the world of Drupal, you may find Drupal a little harder to pick up than most other CMS platforms.
With great power and flexibility comes a steeper learning curve; unfortunately, there’s not much that can be done about that. But if you stick with it, use the support queues and forums to gain help as needed, and truly experience all that Drupal has to offer, you’ll find yourself wondering why you didn’t try Drupal earlier.

Do you use Drupal for your own projects? Why or why not? Let us know in the comments!