Finding the sweet spot

Often, when developing a project, you might find yourself taking very similar decisions over and over.

When facing a decision there are usually two (somewhat opposite) ways to approach the problem.

As a rule of thumb we try to reach a sweet spot between both poles, taking the best features of each side. Consider, for example, the following issues:

"I will have to carefully design this module while not consuming too much time and resources, since development should progress very quickly"

We believe skipping any of the software engineering phases will most likely result in a product of inferior quality, since you will probably fail to produce high quality software when designing without knowing *what* you are designing, coding without knowing *how* you are implementing, or deploying without having actually gone through testing.

That being said, you can't really go very deep into any of the phases if you really want your development process to be anywhere near agile.

Enter agile software engineering.

"There are 10 ideas/features we want to include in our product, although we will only be able to include 2 or 3 due to time constraints "

A good rule of thumb would be to only include those features which are tightly bound to the core of your product. Including features which strengthen the core can only help you focus on the important things.

You might find some of the features - which we assume to be outside of the scope of the "core features" - to be very cool, but how do you know your users are going to like it as much as you do? Only your own users can provide you with those features they are looking forward to.

"The implementation of this particular module leaves plenty of room for improvement. "

Again, why start optimizing before you know for certain what parts you should be optimizing?(bottlenecks, etc).

Furthermore, some optimizations may result in code which is more difficult to maintain.

So remember, think before you act, stay simple, be spartan!

To open source or not to open source?

At some point you might have wondered if open-sourcing your project would be a good idea. There are many benefits in doing so, but you must also understand it's implications. This article will not answer that question for you, but rather lay out some important factors to keep in mind.

Most people, especially companies, are very reluctant to adapt to an open source model themselves. Why would someone put so much money, time and resources into a project and then give it all away for free? What will stop one's competitors from taking advantage of all their hard work, for nothing in return? Well, you can make both of these things work for you.

January 1998, Netscape Navigator has already lost it's dominance of the browser market to Internet Explorer. The decision was taken to open source the project. In the coming years, the Mozilla Foundation releases Firefox, the single biggest threat to the now omnipotent browser from Microsoft. And this is not the only consequence. The SSL protocol, first introduced by Netscape, is made into a standard and chosen as the de-facto way of establishing secure connections. This is a good example of how open source made this product a bigger success than it ever was while being closed-source.



Open sourcing your product should be the consequence of carefully examining the pros and cons of doing so, and not trying to fool yourself on the way. If you think of "open-source" as the solution to getting your work done for free, you are in for a rude awakening. Going open source should be an effort to build a community around your idea and making it an integral part of it. This also means that you will have to invest a lot of resources in making this happen. Your code is probably not clear enough for new developers to understand. Documentation is probably lacking or completely missing. You will now have to coordinate not only your own developers but also a whole community. And keep in mind that if they don't like how you are managing things, they might as well just fork the project or abandon it altogether.

But what can you obtain from all this effort? Open-source projects are favored over closed source projects by many people who find it it easier to trust them, because it shows that the companies that are behind are making an effort to be transparent. Giving anyone the opportunity to take a look into the code will give you a lot of additional auditing over it, allowing you to find bugs sooner and react faster against them. Going back to 1996, when the infamous Ping of Death exploit exposed almost all operating systems to a Denial of Service attack, we find this revealing quote from a security advisory: "[T]he award did go to the Linux community for getting a patch out within three hours (well, 2 hours 35 minutes 10 seconds if you must know)".

But even more importantly, the community will allow you to grow in new directions you might have never thought of.

Occasionally, your community members will not only be individuals, but also companies interested in integrating your techonlogies into their own products and developing them further. In many cases this will lead them to contributing work back, as it happened with WebKit.Apple forked KHTML and KJS into WebCore and JavaScriptCore, which became WebKit and was eventually open sourced around 2005. Since then many companies have not only adopted it as the core of their browsers, but most of them are main contributors who are continuously contributing back - improving stability and efficiency and adding new features. Its main contributors are companies like KDE project, Apple Inc., Nokia, Google, and a large et cetera.

"To open source or not to open source?" is a question where the answer is neither right or wrong. Only you can decide what is best for your project.

Sources:

http://www.oscon.com/oscon2008/public/schedule/detail/2547

http://www.linux.com/archive/feed/38257

Captivating the User

One of the biggest challenges when doing software development is something that is very often left aside: the importance of designing meaningful interfaces that ease the communication between the user and the application.

By communication I'm refering to a much broader concept than a text field, a help message or the use of buttons and windows. I'm talking about making the interface speak for itself without the need of explicit hints.

Some time ago I read an interview with Shigeru Miyamoto, father of the Super Mario series and industry-acclaimed videogame designer. In it, Miyamoto-Sensei comments on the designs of the characters in Super Mario Bros. It is not a coincidence that many enemies had spikes on their backs. The player had to know that running against them was clearly not a good choice. Two decades later we might find it very obvious, but achieving that level of communication is more difficult than it looks.

In the words of Jonathan Ive, Senior Vice President of Industrial Design at Apple Inc. and father of the iPod, "An indicator has a value if it's indicating something, but if it's not indicating something it shouldn't be there", in reference to the hibernation indicators included in the new MacBooks.

And we can apply these same principles to User Interface design. We should minimise , or completely erradicate, the use of help messages and introductory texts, in favor of more self-explainatory interfaces. The user should be able to understand the function of every element on screen instantly, therefore easing the learning curve.

This is especially meaningful on mobile platforms, like Android or iPhone. The short attention span of its users guarantees failure in such brutally competitive markets.

So please remember, try to keep your interfaces as clean and simple as possible. If you can't find the way, you can always add spikes to it!

The World is People

Most social applications nowadays were not designed with mobile devices in mind, and therefore don't exploit most of their unique features. Our idea is to change that.

ActivateMe (name still under development) tries to give an answer to the question "What are people in my city doing right now?". We think a city isn't really characterized by it's monuments, it's bars or it's points of interest but by the people. Therefore it looks reasonable to create a map with them in mind.

The latest technology in geolocalization will aid us in creating said map, without the need of having the user explicitly tell the application where he is or what he is doing. This will allow us to help the users find new places without putting an additional burden on them.

Possible uses for ActivateMe range from finding new places in your city, to finding popular places in foreign cities when abroad. Because what's important is not where the places are, but where the people are!

SpartanCoders is a team of Computer Science students: Pablo Llopis (@pablollopis), Paul Goldbaum (@paulgoldbaum) and Luis Santos (@luiskap), who share a passion for mobile application development. You can find some of their applications on the Android Market.

This is the first post of our project for Tetuan Valley Startup School. More will follow!

Objection Widget

OBJECTION!

Objection Widget is a new desktop widget for your Android device.

Have your favorite characters from the Ace Attorney series disagree for you! Phoenix Wright, Edgeworth, Mia, ...

Instructions:

Do a long press on the desktop > Widgets > Objection!

You will be greeted with a familiar selection screen to add the widgets to your desktop

Big thanks fly out to court-records.net for the sounds

Screenshots:

New Aplication: Auto Silence

This announcement is coming a bit late, but anyway...

Announcing Auto Silence on the Android Market!

The idea is pretty straight forward: get your phone to shut up by itself when you are busy. How? Using you Google Calendar App ( or from the Google Calendar website), set up those events during which your phone should be silent. Mark them by putting "[S]" (without the quotes) at the end of their names, and that's it. The phone will be silenced or put into vibration mode according to your preferences (you can change them from the application) when the events start, and the volume will be restored at the end of them.

If you are a student, set up your classes once at the beginning of the semester and forget about having to silence the phone for the rest of it.

Dealing with orientation change in Android Widgets

As you know, i had some issues with the MineSweeper Widget in G1 devices (and, indeed, in all Android mobiles with physical keyboards).

This issue was related to switching between portrait and landscape modes.

First, i trusted in Android auto-resize, and it resulted in an acore crash when people switched to landscape mode (for example, putting out the physical keyboard), although it didn't crash in the Android emulator (it did a weird resize though).

In this particular case, it was no point on supporting landscape mode (too small buttons = unplayable), so i decided to show an error advice when landscape mode was activated. And this wasn't as easy as expected.

First of all, i realised that i needed buttons references in both portrait and landscape layouts, why? Because the user could add the widget while being in landscape mode, and MineSweeper's data and buttons needed to be assigned to their PendingIntents, otherwise it'll result in an unexpected behaviour, and user would see how widget didn't response when switching to portrait! So i left the buttons part of the layout in the "error layout" setting visibility to "gone".

Then, next problem appeared. Each time the layout changes from portrait to landscape, the view is re-inflated, so you need to re-assign PendingIntents to all layout elements before each updateAppWidget call (and reassign all viewResources too!).

And that's it!

And remember, don't trust Android Emulator and test your app in all devices as posible.

I suppose there are better ways to solve this issue, you can share them with us in the comments!