Shake and bake blogging
Getting started with ScribeFire – ScribeFire: Fire up your blogging
Looks like a really nice way to update your blog on the fly. Check it out!
Tips for mobile developers
For the most part developing for mobile is much like developing for the web. Famous last words. However there are a number of major considerations when making the transition to mobile from Web for the first time. If you’re like me, and why wouldn’t you be? You will find that initially that designing for mobile is quite limiting. Perhaps it is in certain technical regards however try to consider the bigger picture. Now your site is accessible anywhere on the train, in a lecture theatre and at work. A mobile site transcends current Web browsing as it is commonly regarded. That’s just a little “what not” to remember when starting on the rocky path that is mobile development.
Firstly, a disclaimer everything you are about to read is based on my own personal experience. I may be wrong about some things. I know I know it possible. Please let me know if you find something in this post that does not make sense all of you have found a better way to tackle some of the issues that I have addressed here.
Technically the first thing to consider when developing for mobile is the browsers that you’re developed pages will be running on. As Web developers we have four possibly five browsers to be concerned with. Designing for mobile represents the wild west of different browsers with several handset manufacturers maintaining their own browser code. This is archaic however I hope to help you through these times with a list of considerations that I found most pertinent when I first crossed over to mobile development. Some of them may be obvious some of the less obvious however I did personally spend time with a number of the issues that I address in this post… a lot of time.
Don’t use floating DIV tags. Many mobile phone browsers interpret these tags in different ways and it’s difficult to get a consistent look over different browsers. Although a number of browsers do support floating DIV’s many of them interpret these tags vastly differently. A better alternative is using tables. I know these days tables are considered a bit old school however they provide a more consistent look and feel across the different mobile browsers.
Make sure that all of your code is validated according to the W3 the standards. This one may seem obvious however you would be surprised how many pages are being served out from the big players on the Internet that are not valid HTML. Couple this with the fact that mobile browsers outnumber Web browsers almost six to one and you can quickly establish that having a valid HTML code is imperative.
Setting font and font-styles is unreliable. Many different mobile browsers set their own font. Other browsers interpret different fonts in different ways. Sure, set a font however don’t expect it to work on most handsets. Also expect some very ugly looking fonts as there are a number of handsets that use absolutely shocking fonts.
Add the XML document specification. This is a line of code that appears at the top of your pages. It’s the standard XML document tag that should appear at the top of every XML document. This is done due to the fact that there are a number of handset browsers out there depend on your code being a compliant XML document.
Test on handsets. This is mandatory. You may not have every handset under the sun however beg and borrow as many different handsets as you possibly can. The more handsets you test on the more reliable your code will be and the more consistent your mobile site will appear across different handsets. There are a number of mobile phone emulators available on the Internet. These are for the most part are absolutely atrocious. Even the official emulators from the handset manufacturers render the pages differently to the handsets themselves. Sure use them in the initial testing however when going to production these emulators can’t be trusted further than they can be thrown. Believe me I have tried throwing them, it’s difficult especially as I have downloaded them off the Internet and I am using a company computer.
The vast majority of handset screens fall into four different widths. These widths are 176 pixels, 240 pixels, 320 pixels, and 480 pixels. Ideally your code should determine the pixel width of the handsets and serve up the appropriate version of your mobile service to the said handset. In some instances this is not feasible. In this case you probably could get away with a flexible width away our however if this can be avoided I would strongly recommend creating the four different versions of your pages. It’s common to maintain for different style sheets and serve a different style sheet for each pixel width. These days is very easily achieved thanks to cascading style sheets.
If you’re designing a mobile “service” it’s advantageous to allow Web users to access your service as well. This rule can be applied across the board if you are creating a Web service why would you ever want to deny users access based on the hardware they are using. That would be insane. Since nobody this week has commented on my sanity it safe to say that Nine times out of 10 you will find that users are accepting of a site that potentially appears to skinny. They can be even more accepting if the stipulation is made that “this site is optimized for mobile”. You never know, you may even encourage your users to access your site via mobile. To take it a step further you could even create the CSS version of your site designed deliberately for Web browsers.
Don’t use JavaScript. I can hear the collective sigh of thousand developers around the world after reading this one. A lot of new handsets these days are supporting JavaScript however there are quite a number of handsets that do not. To make your site as accessible it best not to rely on JavaScript. At least for the time being while older handsets get phased out. This may limit you in certain design decisions however let’s never forget about users with older handsets.
Use the user agent. The user agent can be used to detect the handset size and all sorts of other goodies. You can also record a number of other useful details about the handset in your database if you’re so inclined. The majority of handset manufacturers provide a link within the user agent to an XML document full of specifications for the given handset. Investigate this XML document and how it can be integrated with your site.
Well as this blog entry is starting to get a little on the long side I’ll leave it there. In future blog posts I can expand on these tips are little more. If there is one thing in particular that you are curious about please give me feedback and I would be more than happy to do a blog entry focusing on your issue.
P2P functionality sharing
Over the last few years web application development has seen somewhat of a renaissance. Back in the dark ages we(Web developers) would write code which contained presentation logic, business rules and data logic within the same files. Now programming paradigms such as “model view controller” allow us to separate this logic out. This empowered Web developers with a whole new method of thinking.
On the downside, we lost some flexibility in the way we worked. For example Ruby on Rails favors “convention over configuration”. This was somewhat of a new direction considering at the time a number of developers were performing hundreds of XML push-ups* per day using Java enterprise edition.
A byproduct of this convention over configuration policy is the fact that Ruby on Rails runs on 94,000 lines of code. That may not sound too bad but when you only using 30,000 lines of functionality out of a possible 94,000 lines there is definite redundancy. Should they take this code out when it’s not used? Well… no, why would they? The whole entire framework is based on convention over configuration and as a result is one of the better designed frameworks out there. However is there another direction we can be taking this?
What about an entirely modular framework? A code base that when created gets passed variables that determine what modules go in to that particular instance of the framework. For example I could choose to have an object relational model module for interfacing with my database, I could use a templating engine for my presentation layer and I could use a migration module to handle creating, removing and versioning of my databases. This method would require more configuration than something like Ruby on Rails however it would allow all of the modules within a framework to be much more loosely coupled, potentially giving programmers more flexibility.
There are also scalability issues to consider. In recent times there seems to be an emphasis on segregating functionality. Sub domains such as “dev”, “api”, and “rss” seem to be commonplace as Web developers place more emphasis on this segregation through their design paradigms. Currently there may be as server for your application, a server for your assets and a server for your data. I believe Yahoo and own in the domain name “yimg.com” just for serving images.
This idea is not new however can we take it a step further? Can program functions start to be the reason to break up server responsibility? Surely if we are heading in the direction of an abstracted “data-backed-web” we can have servers designed specifically for presentation logic. What about a server specifically for business rules? Why not take a top-down approach when segregating functionality and design our frameworks accordingly? if we create a framework and deploy this application to a server why can’t we deploy other parts of our application to other servers. Why can’t we import other parts of application from previously existing applications and take advantage of functionality that has already been written for us? This could make way for an entire peer-to-peer sharing network. However instead of sharing files and media we are sharing program functionality. This would reduce programming to double-clicking on features that you want thus linking them into your application. Suddenly we have a decentralised application that’s loosely coupled materialise before us.
Should I have started this blog entry with the “I have a dream…” line?
*The art of tediously setting up configuration files using XML. A common task the Java enterprise edition developers.
Back, but what’s next?
Well, I am back from my overseas adventure. An adventure that took in San Francisco, Los Angeles, San Diego, Tijuana, Las Vegas, Boston, New York, Chicago, Washington, Toronto, Montréal, Mexico City, Savannah, Orlando and Fort Lauderdale. I think I got them all in. It was a fantastic trip and I learnt a lot. As cliche as it sounds you do find out a lot about yourself when you go overseas and that’s exactly what I did.
The most rewarding thing about travelling overseas is the sense grandeur. You are travelling such a long way seeing places that you would otherwise never see and more importantly meeting people that you would otherwise never meet. Put these factors together and you create a learning experience.
Travelling is its own subculture onto itself. It’s an almost insular world in many respects. Often you spend time with people who you don’t know or you have just met, and it’s difficult to get news from home. This provides a unique environment that’s unattainable whilst living at home. I found this subculture is most prevalent whilst staying at youth hostels. Meeting like-minded people and sharing stories is always an eye opening experience.
One thing I found interesting was the culture shock. Before travelling to the United States I travelled many times through South-east Asia. The United States provided more of a culture shock than Southeast Asia. This shocked me. I suppose in a way, I had expectations about the people from the United States, at least more so than I did from Southeast Asians. For the first two days of my trip I felt almost overwhelmed and very out of place. Once I became more accustomed to American culture I found myself blending in very quickly. By the end I became very comfortable in this environment. I even left with a slight accent (or so I’m told).
Now that I am back home I have to work out what I’m going to do. I would not mind settling back into a job and finding a routine as living out of a suitcase of three months gets old quickly. I am quite happy to settle now and I think for the moment I have nipped the travel bug in the bud. The question on everyone’s lips, well at least mine is what’s next?
Screen casts and a product launch
Mostyle has launched! After what seems like an endless development cycle Mostyle is finally ready to accept public signups. Why not go there today and sign up? You’ll be glad you did.
When you’re involved in a project as closely as I have been with Mostyle there is a certain anticipation and also trepidation going in to what has been a seemingly endless road of development. However in spite of any trepidation Mostyle is ready. As a developer I can say I am confident in the product that the team has built. I think we offer a damm fine solution for people who wish to publish content to mobile phones.
To coincide with Mostyle’s launch I have prepared several screen castes. It’s something I really enjoyed doing and hope to do it more in the future. Please give feedback you have on the screen castes as comments in this blog or even to Mostyle directly.
The first screen cast details creating a mobile site and uploading some content.
The second screen cast focuses on customising that mobile site that has been created.
The third screen cast focuses on a few features with user accounts.
Stay tuned because in the future I will upload a screen cast of the mobile handset using the service. Remember that everything I am doing in these screen castes is totally free so what’s stopping you from signing up and creating a mostyle site today?
The thoughtlessness of youtube
Yesterday I finished work on a video tutorial that outlines how to create a photo gallery using cascading style Sheets. At the end of my video I was quite proud of my work. Sound wasn’t as loud as it could have been nor was the image quality is clear as I would have liked however the video was both audible and viewable.
In the end I had created a 17 minute video that was approximately 44 MB. I go to upload to youtube and in the process note there is a limit of 100 MB for each file.
“No problem” I thought to myself as I continued to read. It was at that stage I realised that youtube limit each video to 10 minutes. So there is both a time and a size limit on what videos you can upload. Why on earth would youtube do this? They are already limiting file size what’s the need to limit length? Are their servers worse or better off? To me the entire purpose of youtube is too enable users to share their videos. When I have a limit of 10 minutes to contend with I don’t feel I am “enabled” it makes me feel the total opposite.
Anyway, that’s enough for my rant. I have a link to the video that I created below this post. Please take the time and check it out and also give me feedback. I am looking to create some more screen castes so if you have ideas or suggestions on what you would like to see me do let me know I would be more than happy to oblige.
Designing “your” Mobile site
As some people may or may not know I’m a developer at Mostyle. I enjoy my job at Mostyle thoroughly. Currently I am responsible for developing the parts of the service that are viewed with mobile devices. We’re getting closer and closer to launch and things are starting to get exciting. The service is starting to take shape technically and hopefully we will be able to start rigorous testing for a “soft” release.
Developing content optimised for mobile devices is both rewarding and challenging at the same time. There are several “what I call” nuances that I have become aware of. Nuances that don’t necessarily apply to Web developers. People often say developing content for the mobile and the Web is technically comparable and that the most part that is true. However there are a number of issues that arise when development is “expected” to be optimised for mobile devices. I have had tuition from people with mobile backgrounds and been able to draw on my own experiences with different handsets to start to understand the mobile spaceand get a real feel for what is achievable.
Initially I found a lot of my gut instincts to be wrong when developing for mobile. Coming from a Web background it took some time to understand what works/does not work on smaller screens and less sophisticated browsers. Initially a lot of the time I found myself going back on designs and layouts changing them three sometimes even four times. It’s frustrating at times however it’s par for the course when learning to deliver to a new platform. As a Web developer making the transition you will find yourself going back on some ideals that you… dare I say “found sacred”.
Discovering all of the nuances when developing a mobile is a personal journey. I don’t mean to sound like Tony Robbins but it’s true. People can make checklists in Blogs such as this one but more often than not developers have to discover these things for themselves. Without going into one of these long lists I will say one thing… contrary to popular belief handset emulators are no sacrifice for real handset testing. Always have this in the back of your mind. Unfortunately, handset testing comes down to trial and error. Save test save test. It’s a rigorous process but it’s the only way to be fully confident in what you’re building.
With out a doubt the biggest challenge for technical development on mobile is covering all of the different platforms. In Web development there is the “big four” Internet Explorer, Firefox, Opera and Safari. Mobile handsets all boast their own proprietary browsers and come in the number of shapes and sizes and screen resolutions. As a result the inbuilt mobile browsers often interpret pages very differently. Being conservative with HTML tags is imperative. Try to avoid lists and tags that will generally produce a verbose output.
If you want to put a positive spin on things think of it as a good chance to get back to basics, like developing pages from the mid-90s. Although the intellectual property, page designs and a server side code is more advanced then back in those days the HTML code being used is almost the same. No JavaScript, limited cascading style Sheets and a limited amount of images. The good old days when Web development was simple… well almost.
It doesn’t matter if you develop for mobile or for Web or even for the desktop you always have to be able to answer the following question with yes. “Do I want to use this site/application/service?”. If you answer is anything but a resounding yes it’s time for a rethink. Your career will be better for it in the long run.
Graduating, Working and Steve Jobs
With graduation a mere two weeks away I can’t help getting excited. I have been studying now for the last 18 years of my life. It’s quite a journey when I look back on it. I think studying will always be something that’s either on the horizon or actively part of my life. I’m finished for now but later down the track I will definitely undertake some postgraduate study.
Moving forward I am going to go straight into my job with Mostyle. It’s something I really enjoy and something that I will be reporting on in the coming months. For those of you who don’t know what Mostyle is there is a small link on the left-hand side. There is just a holder page residing there at the moment but it should wet appetites just enough.
As some people may have deduced from my biography pages I one day aspire to be an entrepreneur. There are a lot of people who are significant role models from me. None more so than the president and founder of Apple Inc. Mr Steve Jobs is very intelligent with a world of experience. I leave you with a speech that he delivered to Stanford University. Every two weeks I watch it to gain inspiration.
Busy busy busy…
Lately I have been busy. That’s an understatement. It seems that when it rains it pours. Currently I am totally swamped with work. That’s part of the reason I have not been updating this log. I found five minutes for this post but I can’t promise much for the next two months. In two months time I graduate. All of the work that I have been doing over the last three years are culminating in the next two months. It’s both a nervous and exciting time for me. On top of that I have my work with mostyle. There is a link on the left-hand side of this page check it out to get some of an idea what I’m doing.
Currently all of my university subjects are in groups. This is both a good and a bad thing. The good thing, much more work is accomplished. The end result tends to be more significant when you work in a group. The bad thing is other group members and the organisation that goes behind groups. Don’t get me wrong I am very happy with the people I have in my various groups howeverIt seems all of my time at the moment is taken up by the organisation of meetings. It’s fine and probably something I could get used to however it’s not what I expected going into this semester. That said it’s given me a fair idea of what I can expect in the future.
I will attempt to post code in this block at some stage detailing various things I have done however as I am not doing a lot of coding at the moment it’s difficult. I am in the process of setting up a repository on google code hosting. This will host one of my end of year university projects which he is mobile project. More information on this as it comes to hand. I have also set up my résumé page and I am in the process of setting up a contact me page. Check them out when they come online.
Rebirth
New log how exciting! For the last couple of days I have been experimenting with different layouts. I have also been writing the “about me” page. Who doesn’t enjoy talking about themselves for a whole page? I plan to post my general ramblings, opinions and anything else that comes to mind here. I enjoy expressing my opinions and I also enjoy logging. If you have any ideas leave comments.
I found writing the about me section very difficult. Some people say the person you know the least about is yourself. In some instances I think that’s very true. When it comes to writing and about me page for example. Maybe it’s because I’m a complex individual :-). I suppose getting the wording just right is the time-consuming part of it. Expressing yourself in a way that is not ambiguous is important
I am currently migrating from another log that I created just recently, I might bring over some of the posts but I don’t think so. This is a great chance to start fresh.
Anyway, I’m going to leave it at that for the first post. Please check out the about me page as I put a bit of thinking into it. I feel that reflects who I am well. Hopefully I will be getting my résumé page up shortly.
Before I go, I will leave you with everyone’s favourite retired Mexican boxer Jorge Paez. In case you don’t know him, he’s the guy with the outrageous haircut and the crazy boxing trunks.
I love this guy, he is not the most fantastic boxer of all time however his flamboyant with a very unorthodox style, a real crowdpleaser.
Out of the box 