Countdown to KDE 4.4 and the new KDE website: 5 days left

Right, it’s a day later and it’s time to see where we’ve gotten with the redesign of the KDE website.

As most of you noticed yesterday, the main gripes were with the header of the design. Today’s update is a small but necessary one – one that shows the start of a new design idea. Very often the start of a design determines its success at the end, and people may or may not take an instant like/dislike to it.

I’d like to stress to those that perhaps didn’t quite get it that this work has already been done, I’m simply posting it out of good humour and I thought people would be interested.

Well, here it is.

Previous entries can be viewed in the WIPUP profile page.


Countdown to KDE 4.4 and the new KDE website

I like dabbling in web development and design and so I was quite happy to be able to participate in the redesign of the new KDE.org website due to release in conjunction with KDE SC 4.4 on February 9th. This was what I was working on during the past week and I must say I’ve learned and experienced quite a lot from trying to contribute.

So every day, including today, I will release an image showing stages in the process of creating the KDE webdesign mockup. They can be found in a newly setup WIPUP project, which can be seen in full at my WIPUP profile.

Today we start off with the original mockup (not done by me) from a user with the alias it-s. Have a peek.


Webdesign usability – confusion or convenience?

Today as work is starting to pick up on the WIPUP project, I decided to tackle something that had been nagging at me for quite some time – the header of the design. Before I continue, let’s take a peek at what we currently have:


When a fresh user views that page, regardless of aesthetic merit (after all, this is a user-based website, not a content-based website) they are instantly hit by a few things:

  • This blue box actually does not contain much information, but takes up half the screen nontheless.
  • This area below the blue box is darker and thus accented more, but contains very useless information.
  • As a new user, I would not want to use any of these features.
  • Even as a registered user, it’s unlikely I would want to use these features more than 5% of the time.
  • What are those icons on the top right?
  • Why is the “upload” and “sign in” button so ugly?

Ignoring a slightly longer load time and slight browser incompatibilities (though that is a fault on my part) we have introduced a good 15 or so new things a user could do simply in the top half of the page – most of which should be ignored most of the time. The important thing here is that no matter how feature-packed you want your interface to be, you have to deal with user myopia, addressed very well by Jeff Atwood.

One way to tackle this problem is by overlaying other web 2.0 technologies (such as this .net developer) above the website – a great example being how Google revolutionised web email clients with GMail. However mainly for personal preference I decided to tackle this one from the ground up – that is, the luddite of a webdesign itself. Here’s my solution:


As you can see, what really stands out is the title of the site – like it should. I’ve cut things down such that it takes up a bare minimum of the page, will have faster load time and requires less non HTML/CSS tricks. The next point of focus is the actual content.

The implications of this are that user choice is now limited to a simple  7 choices. The 3 icons, the 3 links, and reading the main content. The 3 icons are likely to be disregarded almost immediately as there is no textual information as to what their function is. This is good as it’ll only seem important to existing users – those who know how to use them and are familiar with the site. The three text options are easy to read and disregard too – it might be improved further if the search link were turned into a small magnifying glass icon.

The end result is that the user’s focus is on the content. We don’t overwhelm the user and keep their eyes where we want them. Remember: simple sells.


Never gonna give you up.

My previous post featured a sarcastic article that conflicted with all my interests to take advantage of the fact that somebody had hacked my school website to make it rick-roll everybody. They accredited (see synonym “framed”) this hacking to me, linking to my blog in the process. This allowed me to use my blog to broadcast that message to any folks who bothered to click on my name there to say that I was actually innocent.

Of course, I’m no stranger to love, and I myself rickrolled my school during an assembly presentation. But you know the rules and so do I, that was in good humour and didn’t involve giving epilepsy to the lower year parents who were expecting the new on-line extra-curricular activity registration system but instead were thrown at Rick Astley singing his heart out.

A full of commitments what I’m thinking of – I was immediately summoned by people who could join the two dots between the two mass rick-rolls together. “You wouldn’t get this from any other guy“, they said.

I just wanna tell you how I’m feeling“, I replied. “Gotta make you understand“.

Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

… and at this point I figured out that Rick Astley’s lyrics didn’t work too well in a blog post.

The website is full of security holes and I’m not surprised it got hacked. The next day after the site got restored, the hacker had hacked it again and put up a lovely “goodbye, and thanks for all the fish” page with … a shoutbox! This nifty widget allowed the students to go crazy on their thoughts, some impersonating staff members (such as the principal) – but more importantly allowed me to chat with the hacker, who was undoubtedly monitoring the messages. Interesting revelations ensued as he stated that he wasn’t the one who put my name on it (interestingly enough I remember my name was added a good 3 hours after the rickroll was added) and that my guess of an MSSQL injection was correct. Of course, the honesty of such individuals is always questionable, but I’m simply stating what happened. Here’s a screenshot I grabbed of the page:


Dan Fego on the previous post wisely suggested that “the next step is to find the bastard“. Unfortunately my involvement – or better put, lack of involvement – meant that I couldn’t exactly “find the bastard“. Personally like any other student I thought it was a fine joke – until my name was put up there of course.

So that means strolling throughout the school I don’t appreciate “hey, you whacked the site!” or “who did it, do you know?”.

There isn’t that much of an epic conclusion to the story (yet, perhaps?), and I’m back to doing my usual whatever.


The Euphemism Website – the failed idea.

One of the websites I always wanted to make was a Euphemism dictionary. It would be pretty similar to urbandictionary in terms of concept and allow user-defined euphemisms for common insulting phrases. This would thus prevent us racking our brains every single time we wanted to come up with another creative way of saying “my aunt’s maid’s son is better at computers than you“.

It’s also a great initiative to start putting literature to good use rather than the common application of analysing the themes and symbolic imagery behind fictional characters.

Another objective would be to disprove most of the web community do’s and don’ts through the context and artificially induced environment the website will create. For example, users will be insulted constantly, from the minute they enter the website, when they register, log in, or do anything that involves a mouse and a screen. Definitions and euphemisms will have a voting system, except it’s unidirectional – you are only allowed to vote down submissions. I don’t mean this in the rottentomatoes format where more tomatoes means its good, I mean this quite literally. You’re not allowed to say something is good, you say if something is crap, and then we’ll list the least crap and the most crap. Take your pick. User interaction will be minimal – you’re allowed submit and vote, nothing else, users with accounts will be given no option but to receive spam email from an entirely unrelated mailing list, all the time mocking you of your gullibility of registering to such a shady website.

We won’t only break community conventions, we’ll break design conventions too. There will be no clear header or footer. The title will be a randomly rotating insulting phrase (of your choice if you register an account). The content will be single column, left aligned, with a colourscheme worse than my dad’s tie, and a table will be used for everything. One huge table with colspans and rowspans that’ll make the folks in the #css channel choke.

With all that said, it’ll still be better than 95% of the websites on the internet.

Gosh the internet is so full of trash.


GIMPup a Webdesign #2.

Despite the fact I’m smack in the middle of my mock exams…or should I say “slack in the middle of my mock exams”…I’ve decided to make a generic webdesign. You know, just to keep me on my toes. This one has an utter lack of creativity, and is probably your stereotypical design found on the web. However, if any one of you folks decide it strikes your fancy, just contact me and I’ll slice and make it web readyfor a dirt cheap price of only 20USD. This is a limited offer for 1 month only. As after that I’ll probably have deleted the design files.

Well, enough of waffling. Here goes:


Yes, it was made using The GIMP, and it’s part of my little campaign to show GIMP really is worthy. Oh, and the thumbnails shown in the design are all from my portfolio. Comments welcome.


What is FTP?

Dear readers, today I present to you another guest post giving an introduction to FTP by  the wonderful NathanKP. For those interested in suggesting their own topics or writing a post to be published (you will be credited accordingly, we have a new “Spam Us” link up there on the navigation just for that very use :) Enjoy.

Right, a short introduction.

FTP is a protocol, or communication technique, that runs on the internet. Unlike the HTTP protocol which is designed specifically for transmitting HTML and XHTML documents, the FTP protocol is designed to transmit just about any type of file between computers. Since FTP is a different protocol it has its own prefix. When browsing the internet using a browser it is common to access addresses with the prefix “http://”. However FTP uses a different prefix: “ftp://”.

FTP is a very flexible protocol in that it makes file distribution easier when you are dealing with different operating systems, different file storage systems, or character encodings. Unlike the difficulty of setting up a file sharing network between a Unix and a Windows computer, setting up FTP is much easier because both computers can “talk” the common FTP language.

What is an FTP site?

An FTP site is like a file cabinet where files are stored. Like a web server which stores the HTML documents that internet users can access, an FTP server stores files that can be distributed to users. When a user browses to a web url that begins with “ftp://” the FTP server responds and sends a list of the available files to the persons browsing program. This list forms the FTP site itself.

An FTP site can also include security measures to prevent malicious users from performing denial of service attacks or to limit the people who can download the data from the FTP site. For example a company might have an FTP server so that its programmers can all access global project files. However, it would not be good if just anyone could get on the FTP site and steal the companies source code files.

Therefore FTP servers often check the domain names of their users against a internal list of known and trusted people. They also require a login process. For public FTP sites that anyone can use there is often a login where the username is “anonymous” and the password is your email address, which the FTP server will store for future reference.

More secure FTP servers will require a registration process which gives you a real username and password that allows you access to the FTP site.

What is an FTP client?

The FTP client is the program which you use to view and download files on an FTP server. Just like a browser is required to view webpages, an FTP client is needed to see the file list on an FTP server and download the files. The transfer language and protocol used wouldn’t make sense to most users just as pure HTML wouldn’t be very useful to someone who wanted to view a webpage. That is why the FTP client is needed to interpret.

FTP clients come in many flavors. Some are graphical, operating much like the Explorer program on your computer. They show the list of files on the FTP server and give you a convenient way to transfer them to your local computer, usually by drag and drop. A command line FTP client may require you to enter the exact filename of the file you want to download.

However there are many different free FTP clients on the internet, so it should be easy to find one that it is easy for you to use.

This is a guest post from none other than NathanKP from Inkweaver Review.


How to Make a Website Part 1 – The Environment

Creating a new website from scratch into the next killer web-app is always tough, but the journey there can always be a fun one, given that your workflow is right, you know what you aim to achieve, and you’ve got the right tools for the job. I’ve decided to document the creation of The E2 Project, which is basically the re-creation of E2.

During the documentation, I will also teach you the do’s and don’ts of website creation. These are often overlooked, and you’d definitely pick up a lot of tricks that normally take years of experience to develop.

Understanding the resources around you.

Here’s a list of useful resources for the impatient: HTML, CSS, PHP, MySQL, Javascript, Ajax, Free scripts (yes, really), stock images, SVN, Git, Mercurial, Image editing applications (The GIMP), text editors (Vim).

OK, firstly I’m going to talk about setting up your mental and physical environment before you start a project. A lot of people who don’t develop with computer more than often disregard this vital step, and end up rushing or making a mess of things. The first step is to make sure you know what you want your site to do. Will it be a blog? Will it be your online portfolio? Will it be yet another youtube clone? If you know what it does, you should also know what type of person will use it, and what features it should have. You need to be clear on what features it should have, as that’s the bulk of any web-app.

Assuming that you now know what your site is about and what features it will offer, it’s time to make sure you really know what’s going on. Has it be done before? If it has, what can you offer that other sites don’t? What can you learn from existing websites? Are there useful javascript or ajax snippets that can give your webpage that extra zing that makes it stand out? For example, people developing a personal portfolio website might be interested in Lightbox, as that’ll improve continuity on the site and remove layout restrictions. It also makes things look cooler in general. (yes, I really said that)

The next step is to know your limits. You will need to know HTML back to front. Sure, you can forget tags, but as long as you know they exist, that’s fine. As the saying goes, the great programmer doesn’t need to remember it all. There’s really nothing wrong with using cheatsheets. If you do know HTML, make sure you know how to validate it. If you’re epically extreme about this, make sure you can get XHTML 1.0 Strict validation on all your pages. It’s all about discipline, and in the end it helps with cross-browser functionality and compatibility with newer devices like mobile phones. Just take the extra step, and please, oh please, validate your code.

Do you know CSS? Do you use CSS? Any site nowadays should only contain semantic markup and use CSS to effectively seperate design from layout. No matter what you do, do not use tables for layouting. It’s bad. It’s evil. It causes the folks in the #css IRC channel to condemn you to heck. It’s good practice. If you’re unsure what I’m talking about, read this handy guide. Of course, also don’t forget to validate your CSS code.

Do you know PHP and MySQL? True, this isn’t the only way to make sites, but it sure is popular, and hell powerful. How good are you at it? Do you know OOP, do you know MVC (or other framework styles)? If you answered no to either one, take your time to go and re-learn PHP. You’ll might find you’ve been doing it all wrong. Don’t disregard that warning, really, take your time and re-learn what it is.

How big is the project? Do you need version control for it? It’s quite comon for people to dump version control for web projects, even individual ones, as it really makes the developing stage less confusing. If you don’t know what version control is, try search it up, then search up CVS, SVN, git, and Mercurial. You should try it out on your system, get familiar with it and perhaps use it in your next project.

Are you good at design? This does not necessarily mean you have to be a wiz at something like Photoshop (ewww) or The GIMP, there are some really simple designs that look amazing. If you do follow the “Create graphic image” -> “Slice” -> “Create web-app” workflow like most do, do you know how to use CSS in the slicing stage? Do you know how to create a design that won’t break in flexible layouts? Do you know how to solve the never-ending battles with CSS and IE? (Yes, all those dirty coding hacks that are so troublesome)? Do you have good stock graphics? Most disregard stock graphics, but they really add shine to the page. Have you considered web load-times and optimisation when designing? There are hundreds of things to consider, and over time all these things become natural.

Don’t underestimate planning and protoypes.

Don’t underestimate the importance of this step either due to the shortness of this section. User Interface is almost the most important thing that exists on a webpage. Don’t get me wrong, I’m not saying that your backends and server-side scripts aren’t going to do the trick too, it’s just that your site is going to be used. To be honest, change the splash image of any application, and even if you don’t add any new features, it already looks as though it’s had a bunch of action packed updates over the last version. You want to have a clear idea of several things:

  1. The homepage of the site. This is the very first page people see, and the most important of all. This is what gives them their first impression, this is the page that should explain what you do, why you exist, and how you can benefit the user in less than a minute. This will be the central template design (especially for large scale sites) that defines the organisational structure and navigation style used throughout. Do not ever be inconsistent with design.
  2. Your databases. Yes, that’s right. You want to know what’ll be stored, where it’ll be stored, what’s the best way to store it so it can be used efficiently. The word that must be drilled into your head is modularisation. (Not a real word, but we aren’t learning English here, are we?) Basically, you want to use it one way, and any way you might think of in the future. I’ll cover this in more detail when I talk about setting up databases later.
  3. The system and framework. Yes, I stress frameworks again. Too many a PHP script kiddy has spewed out nothing but spaghettic logic. It’s not a fate you deserve. What framework are you going to use? Build your own? Use a preexisting one? Any needed libraries? How should you divide the logic framework into modules?

Work, flow. Work!

The third and last topic I will cover in Part 1 of this series is workflow. This is VITAL. Read that again. That’s the acronym for Very Important Topic Aids Learning. I won’t go into much detail, because all my next parts will focus on workflow too. Some thing you might have noticed here. I did not mention servers or domains. That is NOT your concern. Too much worrying about servers and domains will leave you with a crappy system that’s up 100% of the time. Which nobody wants. You need to make your site? Need a server? Install Apache on your localhost and build it there. Don’t waste money on a half-baked-idea.com.

Workflow is amazingly flexible, but there are some one-size-fits-all that works. The first thing you want to get out of your way is the environment stuff I talked about in the first topic I covered. Know back to front what’s going on and how it’s going to go on. Assuming you have that all worked out, you’d want to create a design using an image editing program. Even if your site is something like Google or Yahoo that has a high text:image ratio, you want to visualise it first. No point playing around with CSS if you haven’t got a clear image in your head. Once you’ve got your visualisation done (good for the home page), create a valid HTML and CSS slice of the page. Split it up into template files and start organising and creating dummy filesystem structures in your framework. Create a couple static non-dynamic pages just to check the flexibility of the layout (stretches, different tags: forms, inputs, divs, headers), check cross-browser compatibility, and then when you’re done, make the home page and fill it with placeholders as necessary.

Now you can start working on the actual logic and system of the website (excluding previous framework setup). The first step is to create all your needed database tables, and choose the appropriate field types and set values. After this, since I use an MVC framework for most of my sites, I like to work pretty much … in that order. I build the models first, build the views, then just connect everything beautifully with the controllers. I generally like to start with building the user system, which is often the key and wire system of a website. This covers easy stuff like database input, form building, error and message templates, and general usability of the site. It’s the perfect “mini-system” to test the effectiveness of your framework, templating system, and helper libraries.

It all pretty much spins off from there, before venturing to code debugging, stress and user testing, hacking preventation, and advertising. Website creation is a huge topic, and unfortunately a text-heavy one too. Hopefully I’ll write part 2 soon!


Learn how to make a basic website framework.

This will teach you how to setup one page for all pages! So it’ll be a lot easier when changing layouts!
Not only that, say GOODBYE to /index.php?page=contact…now you can just have /contact without actually making the directory!
This will ALSO teach you how to have a site which you can easily switch version (like when running parallel systems) when you are working on a new version and you don’t want others to know. It will have password protection which will allow only authorized users to test the version.
Say goodbye to “coming soon” pages!

Ok, first we want a layout…Let’s be simple (just forget validation temporarily, this just an example):

My title.<br />
<a href=”http://site.com”>Home</a><br />
<a href=”http://site.com/asdf”>asdf</a><br />
content will go here<br />

Let’s save that file as index.php. Save it in a directory called “versionname” (you can change this, but remember to change the rest of the code as well) Now, replace “content will go here” with this:

if($page == “”) {
include “/home/username/public_html/versionname/home.php”;
} elseif($page == “asdf”) {
include “/home/username/public_html/versionname/asdf.php”;
} else {
echo “error”;

Basically, it will see what the value of the variable $page is and accordingly, it will display the correct page.
Create a new page called home.php (you can put whatever you want in it), and save it in the “versionname” directory. Then create a new page called asdf.php and put whatever you want in it and save it in the “versionname” directory.

Now try and go to yoursite.com/versionname. It will display your home page. Then go to yoursite.com/versionname/?page=asdf. It will display your asdf page. Let’s say in the future you decide to change your layout…you only need to change one page…the index.php page.

Ok. now instead of ?page=asdf, lets turn it into just /asdf. Go into your public_html folder (or your equivalent of it) and search for .htaccess. Open it up. This is apache server scripting. Won’t go into much detail though. You’re probably annoyed because you want your homepage to be in yoursite.com and not yoursite.com/versionname. Simple, add this code in .htaccess:

RewriteEngine on
RewriteBase /

ReWriteRule ^/$ versionname/index.php
ReWriteRule ^$ versionname/index.php

Now, try to go to yoursite.com. Amazing! The URL didn’t even change! Now to change into /asdf. add this:

ReWriteRule ^asdf/$ versionname/index.php?page=asdf
ReWriteRule ^asdf$ versionname/index.php?page=asdf

Now, go to yoursite.com/asdf. Amazing! It showed the ?page=asdf page!
Ok, now that you’ve done all that, let’s say you want a new version, but you don’t want to delete everything and setup a coming soon page. Create your new version in a directory called “versionname2”.
Now, you want people to be able to access your new version, but not all people. So here’s what you do. Add this to the top of your versionname (not 2) index.php:

header(“Cache-control: private”);
if( $_POST[beta] ) {
if( $_POST[pass] == “yourpassword” ) {
$_SESSION[“beta”] = “1”;
if( $_SESSION[beta] == 1 ) {
include “/home/username/public_html/versionname2/index.php”;
} else {

And now, add the form below to wherever you want the verification to be:

<form method=”post” action=””><br />
<input name=”pass” type=”password” class=”input”>
<input name=”beta” type=”submit” value=”betatest”>

So now, when you type in the password “yourpassword” in the form, you will be browsing your new version, with no edited URLs! Of course, to make it fully compatible you need to add the if $page=”” statements to your versionname2 index.php, but that’s simple to do.
Ok, you’ve finished coding your new version. Simple, just go to your .htaccess, and replace all the /versionname to /versionname2. Done! You’ve succesfully upgraded your site.

Note: this is very basic but I hope it has helped some of you.


How to choose a website host?

This is a much discussed subject when beginners start on website making. I myself have searched long for a good host. Well, let’s keep this straightforward and to the point.

First, you need to know what your website will offer. Will it only contain text? Will it have videos? Will users be able to submit items (articles, messages)? Will you need a domain? Those sorts of questions help you to identify the key features of a webhost that you require. If you will just need the ability to post text, any webhost will do. This is the simplest item. However, if you need to post a lot of pre-written text, with lots and lots of archives, you might consider getting a host that supports FTP access. If you require large videos and image files, you would probably look for the best bandwidth and file capacity in order for you to host and users to view these files. You will also require an FTP client, which will give more convenience to you when transferring these huge files.

If you need user-submitted content, you will definitely need some sort of database support. Unless you are confident you can work with just flatfiles. You will also probably need a good control panel to configure your statistics. For this, the webhost is up to you, but I find that I prefer using CPanelX which is available from most Linux servers.

Will you need a domain? Almost all paid hosts allow for this, though you will have to consider whether or not you want more than one domain or not. (see Addon Domains) However, more free hosts have been giving domain availbility as a feature, so I would be sure to check first.

Finally, is it worth to pay for your hosting? If you’ve just had a brainwave about making a website, I would say no. There is no guarantee that you will keep the website. (Trust me, not your brainwave, as you are deluded by excitement) Most free webhosts are sufficient for people, but if you are planning to have a huge website, don’t get a paid host right away. Start off free, but make sure that your host has the ability to upgrade your account to a paid service should the need arise.

I hope this quick guide helps you.

Want me to recommend a webhost? These guys are great.