Web App: Juvely

Well firstly let me apologise for the lack of posts recently. One of the problems of being a student is that once in a blue moon you will have work to do….

Anyway, on to the content. The other day I had an idea for a new type of wiki to aid colaboration, it is early in the research stages and I don’t know how much will come out of it, but I decided to create a prototype, in Rails. This led me to question whether CakePHP was the best choice of language for us to use.

Originally we decided to use PHP because both James and I had used it extensively (James had only done a tad of Rails), I started creating a framework originally but then came across CakePHP so we decided to use that instead. In the end I did the majority of the programming as James was better at designing than me, and this didn’t take up as much time (he has work to do at uni :P).

So now lets get onto some of the problems with CakePHP, which are mainly due to it being PHP based. Firstly when you fetch a database record, rather than getting an instance of a class (as in Rails) you get an array. Although this doesn’t sound that big a deal it means you need extra code which decreases readability. Next up is how variables are sent to the view, in Rails you just create a global variable, where as in CakePHP you need to call a function. This again means extra code which decreased reability.

Another thing about models being classes, quite a major point, in Rails you can call functions in a model that affect the data in that instance of a class, in CakePHP you can’t (AFAIK) so you either have to add extra code to your controllers or write a function in the model that fetches the relavent data, updates and saves it.

Well, I think that is enough about why CakePHP isn’t as good as Rails, lets get on to the good stuff! If you don’t want to learn another language, and want a framework for PHP then CakePHP is an excellent choice! It supports both PHP 4 and 5, it is rather easy to learn (the documentation is nice and short so you can pick it up easily) and has a nice way of debugging (printing out SQL queries and the results at the bottom of the page, Rails doesn’t have this so you have to follow the oversized log files).

So what are we going to do about it? Well at the moment not much, we have got well over 150kb of CakePHP code and I don’t really feel like rewriting it all just yet. We shall wait and say if any major problems crop up, and if so give that big task of rewriting a go. Although it might sound bad, I shouldn’t think it would take too long as getting the views right is always the biggest challenge when implementing a new feature! If you are interested more about how CakePHP stacks up, here is a good comparison!

It’s that time again, Luca is heading back to university on Monday and I’ve already been back for a week. With the May exams coming up we’re both going to be doing revision, so the development process will slow down. We will still try to update the blog as often as we can.

The easter holiday was pretty amazing. We both managed to get a ton of work done on Juvely, we were able to make important decisions, I also managed to read the Getting Real book in an evening which made me think harder about some of the choices we’ve made in the app. We completely re-thought the “settings” pages. Originally the app had alot of settings/preference pages, Although Luca and I knew exactly what settings were where, for a user it might become confusing. We’ve scrapped the whole idea of the settings/preference pages. We’ve decided we’re going to make the decisions as far as simple settings go, for example how many tickets to display, how to display them etc. Many other small decisions/revisions were made as well, you can download one of the Revision files here just to get an idea of the process (this one was typed up whilst sitting on the plane on the way back to university).

On a getting things done (GTD) note. Taking my MacBook everywhere is great, if I do come up with something or think of anything, whether it’s big or small i can get it down. Sitting on a plane for an hour gave me a great chance to look over alot of what we have done. I come up with a ton of possible revisions, and design improvements. Getting alone/quiet time is key. Wherever it may be, on a plane, in a public library, at the park, it really gives you time to think hard about your idea. Having no distractions really allows you to get in the zone and focus. Although I was able to get work done at home, my little brothers and sisters were a constant distraction, it’s fair to say they missed me and I missed them but as far as concentrating goes, it’s hard. This could be anything though, whether you have kids, a hungry dog, a hungry cat, something on the TV. It’s good to get away from these distractions, go off by yourself (take your laptop if you have one or just a notepad will do) find a quiet place and focus. I was able to think clearly about important decisions. This is something I would highly recommend. I would love to know how other people get things done, so send me an email james at juvely dot com or post a comment!

Remember we still need more beta testers for when we’re ready to launch it. Sign up here!

The other day James revealed his first mockup of the app website, and hopefully like myself when seeing it you loved it! His original mockups for Juvely near enough completely different to what they are like at the moment, he said he is going to put a post up about how his designing has progressed so keep an eye out!

One of the things on the mockup we said is that Juvely is “smart, simple and elegant” (originally sexual instead of elegant - lol), so I thought I would reveal a few things to explain how they are so. I expect a lot will change before we release the beta.

I will start with a couple of pics from the staff center, first is the Dashboard which is what you see when you log in.

At the top we have a ‘Whats going on?’, which as you can guess tells you what is going on. It has easy to access links to unanswered tickets, unassigned tickets, and replies that need attention as well as telling you how many other staff are online. I expect the colours are going to change to highlight some changes, and as you can see the number of support staff online has not yet been implemented.

Next is the Recent Tickets, which shows you recently updated tickets. The priority is shown simply as well as when the ticket was last updated in an easy to read human form. The star next to the priority means that the ticket has an unread reply, Iwe need to rethink these as at the moment they are not very easy to understand. Under the ticket title is a short sample of the original ticket message left by the user.

Lastly down the bottom we have the Recent Activity which shows what other staff members in the helpdesk are up to. The icon varies depending on what action the staff member has performed. Again we have easy to read dates. The number of tickets and number of recent actions shown are both configurable, in the screenshot I have the limit set to two so everything fits in nicely.

Next up is the view ticket page. The top bit shows you various details such as the status, whether the ticket is open or closed, who it is from (User is the name of the user, we might change this to display their email address as well), when it was submitted, the severity, department and lastly the priority. We have used AJAX where we believe it to be sensible to provide the best experience for the user of Juvely but also (unlike quite a few recently created apps) allowed people who do not have Javascript enabled to use the site just as well. In the big yellow box is the users initial message.

Next we have the section that allows you to reply, looking back it looks to be rather small so I expect I will add a link to expand the textarea. On the right hand side as the moment there isn’t very useful information. Our “formatting rules” (rename needed) are textile markup, so I expect we will have a few examples here. At a later date we may add a WYSIWYG editor, but I shouldn’t think so to begin with. Under this we have options, such as having an email reply, an SMS reply, and to closed the ticket. Lastly you can attach files if you wish.

Under the reply sections we have the current replies to the ticket. The reason why the ‘View Current Responses’ bit has a red background is because you can toggle whether that section is displayed or not. We originally planned to have a few more sections but as we don’t this seems rather pointless so I’ll probably get rid of this. The responses are laid out easily to read in descending order of when they were posted. At the bottom of the reply you can see any attachments that were included with it, and how big they are. Clicking on the name of the file will download it. The icon will vary depending upon the fietype.

Lastly under that is an RSS link for this ticket, all tickets and ticket lists have RSS feeds at the moment which let you view any replies and any changes made to the ticket.

Well I shall leave it at that for now, I expect I will post later on this week with a few more pages to tease you with!

If you are developing an app I would highly recommend doing this yourself, I am actually quite suprised at how many things I have thought could be done better another way by looking at it in this way, where as just normal development you don’t take any notice of the little things.

As before, if you are interested in being part of our beta signup!