Week 5: What you see is what you get

There's a cool acronym that I've always liked as a developer, that's pretty common among different platforms - WYSIWYG; It means What You See Is What You Get. Essentially, when developing a visual interface, a common tool that is provided is a WYSIWYG editor meaning you basically drag things where you want, and where you put it is where it will be in the final product.

One of the cool things that Android Studio provides is a very good WYSIWYG editor. This certainly makes things easier. It's still work, but for a guy who can't even draw good stick figures, this helps out a ton. I spent a lot of time this week playing around with Android Studio's editor. So far, I've really worked on row items, headers, footers, as well as the Action Bar. Now, this it isn't much in way of the actual app, but it is some fairly decent progress. None of it is final; Actually all of it needs work, but I think it's a great start.

Here's some screen shots of some of the progress:

An example a single Alarm Clock Item(imagine a list of these)

An example of the header that is in the
ringtone browser.  Imagine this at the very top
of a list of ringtones 

An example of the button that would  be found at the bottom of
a list of Ringtone Playlists.

An example of a Playlist item that would be
found on the home screen. It shows where
playlists are in use

This is an example of the Ringtone Player that would be found
in the filebrowser. The player will be black but the list
of ringtones will be white. Try and imagine what that looks like

An example of a Ringtone item in the
File browser. I'm not sold on this one. Expect
this to change

This is an example of a possible alarm creator. This is basically
what Android provides, but I kinda like it. It will depend
on how it looks once it's integrated
 

A very early look on the action bar. There
is a sort button, and a add playlist button; The
Color matches the new icon, which I like

A very early look at the navigation bar. This is not even close
but I am using the navigation bar as the way to navigate around
the app

Now as I said, this is all very early. It is all subject to change. I've done this first so that I can use placeholder pieces to put together a prototype, which then will weed out the good, the bad, and the ugly. 

Feel free to comment what you think. I appreciate your opinions. If you really don't like something, let me know and I'll take your opinion into consideration. GUI's have previously been my struggling point, as some of you already know, so it's my goal to really take the best opinions, including my own and make something great.

Anyway, it's late. Have a wonderful week!

Week 4: Practice makes perfect

It's been a unconventional week, as far as development goes.

Just recently, Google has been encouraging developers to make a pretty big shift in their development process. This week has strictly been focused on meeting these requirements

Quick history lesson: When the Android SDK was released, the software provided to write Android apps was a plugin for a common Development program called Eclipse. It was fairly simple to use but had a lot of limitations; None the less, it was the defacto way of developing and debugging Android apps. At the end of 2013, Google released an early version of an Android only development software called Android Studio. In December, the official version of the software was released with a request to all developers to move their development to Android Studio only.

The difference between the two is actually quite large and it has been a difficult learning curve for me, so I decided to take a course on Android Studio. It's comprised of most of my free time this week, and probably going to carry over next week. It's in my plans to also take a course on some of the new Android features. I'm driving to bring the very best, and the more practice I have with creating a good User Experience, the better I can deliver on my promises.

Last, before I close this blog, I want to talk just a little bit about the testing I've done so far this week. If you remember from last week, there is no GUI right now, so it's a little difficult to work with. Nonetheless, currently the app only lets you apply a playlist on application ringtones using a temporary ringtone picker I made. Basically, you go to any app and click set Notification Ringtone. So far it has successfully shuffled and played the next ringtone on the playlist. So far I have not had any problems, with the exception of some cosmetic and technical choices I was using specifically to test. There is a lot more functionality already put into the app, but this is the only thing that can be done through the barely existent GUI. Really exciting stuff are on its way. Hopefully, once I get through all the courses I have planned, I will be well on my way to get the GUI's I've drawn and designed.

Anyway, Hope y'all have a great week. I wanted to share some images of where the magic happens. I didn't take any pictures of my whiteboard wall that I bought, but here's my desk and my gadgets that I am using to test, and some that I have ideas planned for in the future. Enjoy :)


My many screens where the magic happen.

My devices. Amazon HDX, A Lumina 520 Windows phone, an LG G Watch, HTC One M7, HTC One Max, Samsung Vibrant, Google Cardboard, and I use a HTC One M8 as my main phone :)

I officially got my degree this week as well. This is the reason ShuffleTone has been postponed for so long. Sorry about that :)

Tyler -- DizWARE

Week 3: UI Design

I've been developing software for almost 10 years; Over time, I've learned new strategies to overcome challenges. When you have an idea and you want to turn it into something real, it usually requires plans, backup plans, backups of backups; Reams of notes, scrapped ideas, overzealous desires, drawings galore, conversations with others that lasts weeks, but mostly it's a giant, unorganized puzzle to be solved. Each piece must be studied intently, as it is your job to put the pieces in the right place and in the right way... If even one piece is turned upside down, the entirety of the
picture will be thrown off.

Each piece requires a very specific amount of attention. For example, if you designing your very first car, it is important to study and understand the workings of both the gas, and the brake system, but just studying them individually is not enough. It's absolutely essential that also study how the brake and gas work together; What kind of transitions can be created between the two? What would happen if the user interacted with both at the same time, or what if the user quickly switched back and forth between one and the other. These details can completely change everything about the direction of your product... It is the difference between life and death.

Luckily for me, I don't write apps that are "Life and Death" risks, but its important to me to always deliver the very best to you. It's been my priority to take my newest and greatest skills, conquer my age old problems of previous versions, and to hopefully enrich your life with the final result. I want that, and focus on that. As I look back in time to old versions of ShuffleTone, I can easily and safely say that the hardest part of every delivery I've made has been the User Experience along with the User Interface.

I usually have an image that sits in the very back of my head... When I close my eyes I can see it almost perfectly, but I can't see it well enough to know exactly how to create it. I draw and draw and draw till I feel I have gotten close to what I see, then I write every line. Each element on the screen is given specific rules to tell it where to sit, how far from other elements to be, and even what to look like. After these files have been written, I make an almost insane effort to break it; Running it on different emulators, physical phones and tablets; and yet I don't see what I see in the back of my mind. It's never right; It's never perfect; Maybe a mindset of an artist, but I think it's the mindset of someone who knows how much better it can be.

You are probably wondering, what's my point. Well, my point is GUI's are hard. Really hard, in fact. It typically takes a lot of patience, motivation, drive, time, and creativity. It takes knowing what you really want, and why you want it. I am at the very beginning point of creating what I see in my mind. I wanted something physical to share, but I don't have anything yet. Instead, I filled 8 pages of notebook paper with lots and lots of drawings, good and bad, as well as some that need improvement. They still need work, but I really feel good about it so far. Last week I talked about the focus of this new ShuffleTone being playlists. As I've been designing, I just can't help being excited about it... It's perfect; It's intuitive, functional, expansive, fairly modular, and I think it's going to make for a great User Experience.

Anyway, things are progressing well, and I am excited to continue to share as things move forward :)

Have a great week!
Tyler -- DizWARE

Week 2: It's all about Playlists

Hey everyone,
I actually want to use this post to share what is happening so far in ShuffleTone, and hopefully share why I am so excited.

First and foremost, there is no Graphical User Interface, so there won't be any screenshots yet. I have mostly focused on the back end, trying to future proof the code and make it incredibly flexible. Expect some in progress screenshots in the future.

Playlists. This is the magic word here. In the past, a lot of the strength of ShuffleTone has come from it's playlist system, but I never really put it up front. It is probably the one thing that has changed the most from ShuffleTone's inception, and it's always been the strength of the application. Well. I'm going further with it. I feel strongly that every user should be comfortable making and using large numbers of playlists with capabilities that extend past just calls and just texts.

With that in mind, there is a new system that I have added called the "Radio" system. Basically, you create a playlist, this playlist is now available to be set anywhere that you feel you would like random ringtones; Once set, a "binding" is created that links the event to the playlist. When the event is hit, the "binding" loads the playlist, pulls out the next ringtone, and then calls a "Radio" that is specific to the type of event.

Here's 2 examples to give you an idea. Lets say I make a playlist called "My Playlist" and apply this to both my calls, and my Gmail application. 2 bindings are created here, binding "My Playlist" to a phone call event, and also binding "My Playlist" to my Gmail notification event.

Each time I receive a call, the "binding" loads "My Playlist" and picks the next ringtone; It then sends that ringtone to the Phone Call Radio, which sets the ringtone to my default phone call ringtone.

On the other hand, when I receive a Gmail notification, the "binding" loads "My Playlist" and picks the next ringtone, just like phone calls(or any other event), but then that ringtone is sent to the Application Notification Radio, which will launch a notification with the ringtone attached, essentially playing the ringtone received.

If there is a way to know when to launch a ringtone, there should always be a way to establish a Radio to figure out what to do with the ringtone. Truly there is a large subset of possibilities here. This includes the ability for event playlists. Maybe you want your Christmas ringtones during Christmas time, but any other time you want your cool jams; An Event Radio would handle that quite well; Or maybe you want work appropriate tones during work hours, and your jams any other time; Also possible with this new system.

There is still a lot of work and testing that needs to go into this, but so far things are well on their way :D

Until next week,
Tyler--DizWARE