As I continue work on V3 of PYKL3, which has concentrated thus far on migrating some of the UI elements to something yet more flexible, intuitive, and easy to use, the data access and storage framework, and identification which features should be in the initial V3 release, I'd like to create more of an open discussion, step by step on design challenges that are faced and decisions that need to be made. With the aim that a lot of user's feedback is going to get us faster to a design that is going to work better the first time, I'm really wanting to more closely involve the core group of users...namely, you, the beta testers. Seeing as if P3 has always been a tool for higher end users (and I have no intention of dumbing things down), I definitely want to keep it going in the direction of the more advanced user. That's not to say, however, that some things can't be simpler and more intuitive/streamlined. P3 has always had a LOT of customization that just isn't possible anywhere else. If there is anything, I want to make it even more customization, yet try to make it simpler to user. In this case, it's not so much the look and feel of the UI as a lot of thought has gone into that aspect. But rather, a lot of the stuff that goes on in the background to make an application, well, just really nice. In turn, this has the side effect of possibly simplifying the UI even more.
So, here's where I'll start this little experiment with the more collaborative approach. Yes, I'm the one and only coder, so I can only do things so fast, but with your ideas and input, the product can be made even better the first time.
I want to address this issue up front in case any of you are wondering about the future of P3. While I have lots of self motivation to keep developing P3 to be a more and more robust platform and don't see myself running out of energy anytime soon, I do want to share with you what would happen if I elected to no longer work on the program. The simple answer is that my intent is that the code would become open source and the community could keep it going and expand it for years to come. I would assert that I doubt you would see this action out of any corporately run program. They are just too wrapped up in intellectual property concerns. I'm not. That said, in the meantime, I have two wonderful and smart kids that will need to get through college and the oldest is 3 years from starting.
A lot of new, more streamlined, backend capabilities have already been coded into the P3 framework from file management to data and metadata updates, etc. Still, some of the more visible aspects, such as exactly how GIS data is handled and managed remains under investigation. But, let's try this collaborative effort starting with something seemingly simple, but yet complex in its own right....and make it specifically with regard to weather data.
One of the first areas that I'd like to solicit input on is location. There are many facets to location in a weather centric application...many that one doesn't think about, but can be a development challenge. The Android location capabilities in the SDK have migrated over the past 5 years and with V3, it's time to revisit how location is managed. I think some startup customization remains very valuable to users, such as the default radar option. However, it doesn't stop there. Location, especially when one is traveling, introduces complexity. Weather data, as a whole, is unique. There are many scales on which to view data. Global, national, region, local, etc. Each has it's own unique advantages and I want to continue building the right framework to handle weather data effectively and efficiently. Google Maps is definitely not the right platform for many reasons. Using logic similar to a route-finder, too, is not the right answer either. However, each of these has elements which can be part of the solution.
As a start, Imagine that P3 can be panned/zoomed in a framework which no longer uses a radar-centric coordinate system as it does today (think Google Earth.) There are new considerations and use-cases that involve location. It is these use-cases that I'd like to collaborate with you. Yeah, I know, everyone wants something that "just works", but such a definition is different from user to user and this is where I'd like to get the range of what users (you) want and see what's possible.
As the discussion continues here, I'll be formulating a Google document to capture the various cases. When it looks like some degree of consensus is reached, I'll publish it for review with the group. To my knowledge, no weather application (outside of AWIPS used by the NWS) has ever had such a user-involved design process. So, here's your chance to share how you think things should act.
Is everything possible? Well, not exactly. We do have the limitations of the Android Platform and CPU/Memory/Texture space constraints, but things are a lot better now than when P3 V1.0 was released in 2010.
So, here are the areas for comment: (I'm sure this list will grow)
A. Program startup. Android defines 4 main location strategies which fundamentally boil down to high precision, low precision, low power, and no power. Plus, there are options for users to select a default radar. What is the flow of decisions that need to be made? Plus, what should the default be? My initial take is that the last known position should be use to auto-select a radar. Perhaps we would not want to include TDWR sites (or would we?) (Consider what would happen if you travel since the last time the app has been opened) That said, how old should that position really be before it's not considered (1hr?). If it is that old, then what should we really do?. What type of positioning should be used (high accuracy, low accuracy, etc?) Consider also that rural areas (with greater spacing between cell sites) will provide much more granular coarse resolution than in cities. So, think about the spectrum from very rural to metropolitan. What other situations may exist?
B. Bringing back to foreground. Say that the app has been in the background for a while, and the user brings it back to the foreground again. Should the location be queried again with the closest radar selected automatically or not? Should the user be prompted to switch to the new radar? Or should it just pick up where it left off?
C. What about cases where the user is on a storm spotting venture and the user becomes closer to an adjacent site. How should we handle this case. Should we automatically switch the user to the closer site when the user is X% closer to the adjacent site? Should we prompt the user if a new site should be selected? Should it be user selectable whether to auto-switch or not? Should the prompt to switch be displayed or not? Think about your experiences when traveling. What would you envision the "nicest and most elegant" means of handling the location. What would make your use of the program easier in this case?
D. Consider if we wanted to alert the user that they entered a warning polygon. In this case, almost certainly high precision position is required in my mind. However, I may have a different perspective than you. Should it be an alert in/out of the polygon or should it be x km (or miles) near a polygon? Should such a feature even be included at all?
Note, that at this point, I have no intent on making an alert for warnings if the user is within a warning, but P3 is not active. This is due to both technical and liability reasons. There are a lot of folks out there that flat out would mis-use such a feature blindly. Unlike so many organizations (media) that want to dumb things down, my aim has always been to help educate users and bring their knowledge and awareness up. This technique tends to save more lives. I'm a big proponent of the greater good of society rather than individualistic tendencies, so please consider that in your feedback. You may or may not like that, but at least I share what my position is so I can be clear.
E. Do any different considerations need to be made when dealing with data types other than radar. What about surface data or satellite or something else? I won't elaborate too much here, but let your mind be open to any type of data that could be conceivably displayed that is related to weather. Think big. Let's use the funnel approach to filter down to the core needs.
Overall, the vast majority of P3 users are extremely satisfied with P3 as it is today. That said, it can be made better through collaboration. If you'd like it to head in this direction, I encourage you to contribute. As with anything, the more you put into something, the better the result will be.
A few final words. I use weather data (including radar) in my "day" job extensively and have a real focus on public safety and education. I firmly believe that a smarter society will make better choices than one that is coddled. No aspect of weather is simple. Even something as simple as taking the air temperature has complexities. As such, I do have some opinions of how things should work. However, I do encourage folks to challenge me if you have opinions to the contrary of how I lean. Just be prepared to provide detail as to why you think things should be different if i push back. I do listen but am very logical. Such discussions are very, very healthy and create a better end result.
Thank you for your consideration to contribute. Let the discussion begin here. If you want to have a one-to-one conversation, just send me a note to firstname.lastname@example.org
P3 is a project that I develop in my free time and my family is very supportive of my efforts.