Somehow amidst the craziness of December 2012, we held an in-house app competition coined the "Jedi Challenge". The topic for the Jedi Challenge was to interact on the move. The application needed to be mobile and multi-user focussed. In true SilverStripe fashion, there were no restraints or barriers. Entrants were enouraged to allow their actions to be "guided by whatever mystical force controls your destiny." Righto! The competition upped team spirit and allowed our designers and developers to expand their creativity and openness to new ideas and new solutions. There were really no boundaries with this competition, with entries ranging from quirky to surprisingly useful. Check out a snapshot of the top three below.
The iCook app won first place, and was created by Designer Bee Intrasuwan and Front-End Dev Saophalkun Ponlu. A seamless combination of creative thought and clean design.
Motivation behind the project
There are a lot of cooking and recipe apps out there, however they are either unpleasant to use or their contents are generated by their own experts. This is only useful if you want to pick something off the shelf once in a while. What we are missing is the middle ground. We want an application that we, passionate cooks (professionals or amateurs), can collect our own recipes, share them and easily explore those of like-minded others.
We think a good app needs good design, so we invested a lot of time up front to come up with an intuitive user interface. We spent around 20% of our time alone on sketching up the UI. We got a lot of inspiration from existing apps on the market. Interestingly, the ones that inspired our app design were not cooking or recipe related apps.
The main challenge for us was the Add Recipe screen. We wanted to make it quick and easy for users to add their recipes as a lot of information needs to go in at this stage. Our solution was to allow the user to enter ingredients in plain text and the app will turn the text behind the scene into a nicely formatted list.
After the UI was finalised, we fleshed out the skin of the app. We wanted a presentation that was as clean and simple as possible while maintaining the main elements of a recipe app. The main idea behind the design was to have a prominent photo area because, as the old saying goes, a picture is worth a thousand words.
Due to the time constraints, as in many projects, we had to cut down on some nice-to-have features to get the app completed and polished on time. The following is the list of features we would like to add in the future:
- Local cooks and recipes (using geolocation to discover nearby cooks and recipes)
- Offline storage for bookmark recipes
- Social sharing (Facebook & Twitter)
- Inappropriate content reporting
SilverStripe allowed us to get the project up and running in just a few hours and to focus on the business logic.
"Street Wars" is a real-time, multi-player, online game, created by senior developers Mark Stephens and Normann Lou. The entry aimed at using the most advanced technologies, frameworks, and concepts, such as SilverStripe Express, Responsive Design, WebSocket, Backbone, Bootstrap, and of course, CSS3 and HTML5. After hours. Not trying to do too much at all.
The game has two teams, representing the Empire and the Rebel Alliance, fighting it out on the streets of Wellington in a capture-the-flag style game. Players use their mobile phones to figure out the location of their opponents' base, and the first team to reach it wins. All the while, the admin can watch the whole war on a Google map, with real-time player location.
The game has four phases:
Forming: waiting for players to sign in and select a team.
Preparation: waiting for one player from a team to set-up the team’s base location.
In process: while the game is active, players walk the streets and try to get as close as possible to the opponents’ base to win. If two individual players from different team come too close, the central server puts them into hand-to-hand combat - the first player to respond wins, and the other one will lose ability to get location updates for a while – frozen.
Completed: When any player from a team is close enough to the team’s opponent base, the whole team wins and game is over. All the players will be updated with the game over status at once.
The cool features
- The whole application uses only one template - it contains different views - according to the game status, which will be updated on the fly using a web socket connection to the game server. The client side of the application is written using backbone.js.
- The game logic is implemented in the web socket server within a SilverStripe application. The ORM is used for recording game and player state.
- The Landing view uses CSS3 technologies, such as scrolling 3D text for its flash-like branding.
- After a player login, online messaging is available for player/admin to send message to one another, which is also implemented by WebSocket. Geolocation is used for each team, setting its base location and updating individual location during game in process. The player’s location information is sent to the server and propagated to all players every five seconds.
- As an admin, all players location and their movement is captured in the Google map.
- As an admin, some debugging actions are available, e.g. force team players from different teams are able to kill opponent by sending conflict.
- Using Bootstrap framework for the games template makes it responsive to any browsers/devices.
Watch the screencast.
Retronaut is a developer diary designed to assist developers using Scrum to record and prepare data for their retrospective at the end of their Sprint, so that they may create meaningful and SMART actions to improve their productivity in future sprints.
Retronaut was developed by Robert Curry, while Project Manager Luke Percy took care of, well, project management, testing and a little code!
Here at SilverStripe we use the Agile Scrum methodology, which breaks projects up into deliverable cycles called ‘Sprints’.
A ‘Retrospective’ meeting is held each Sprint, which allows developers to review the past Sprint to ascertain ways to improve their productivity in the next Sprint. This relies on remembering and communicating what went well and what didn’t go so well, which can be difficult as some sprints can be as long as three or four weeks.
Our Jedi Challenge concept was to make an app for recording and collating the necessary data in an intuitive and easy-for-all manner for every developer in a Scrum Team.
At the end of each day, a developer can log on to record how they felt the day went. First, they would sketch their mood during the day by using their finger to draw a line on a mood graph: the higher the line, the happier the developer.
At the end of the sprint, it’s time to have our retrospective! Each developer can view the collated mood graph to see how the whole team felt during the different parts of the Sprint, as well as which tags were most common among the team.
From here, the team can vote towards which group of ‘Sad’ tags they would like to discuss further. From this discussion, the team can attribute meaningful actions to take away from the Retrospective.
Post your comment
Comments for this post are now closed.