Thursday, April 4, 2013

GUI-Mockup

Dear readers,

this week I started with some GUI mockups.

----------------------------------------

Start Screen:


Related user story:
John is a meteorologist. He has many sensors in a field study each generating temperature readings. In order to conduct his research he wants to have a general overview of all the current sensors he is currently working with. He also wants to see in his overview, if the data is generated from a sensor or a construct. A construct is a combination of several sensors.

 Adding a New Sensor:

Press Button „Add“ on start screen.


Related user story:
John has already stored his data securely in a sensor. He wants to add a new sensor to the system for further processing, like creating new constructs or showing the data.

Link two sensors to a new construct:

Press Button „Link“ on start screen.


Related user story:
John likes to create visualizations that combine humidity data with data on temperature that another scientist has been storing. He wants to save these combinations of data securely to show them to his colleagues in a few weeks.

Visualize data:

Press Button „Show“ on start screen.


Related user story:
John wants to view his new data combination to Alfred graphically to show him his results. He can show Alfred the raw data (Timestamp and Data) or he can visualize it by choosing one out of two visualization options.
----------------------------------------

The above shown GUIs are examples, how I want to realise my program.
Some of the buttons are already working, but not all of them.
I haven't started with the visualization part yet.

Open questions at the moment:
  • The visualization-window shows the date of the sensor data
    Should I store a date in my GIT/SVN .txt.-file which I display here.
    Or is it better to show the date, when the actuall data has been stored in the versioning system? (reading the log-File of the versioning system)
    Currently each sensor is just a text-File with data like that:
    93
    94
    95
    But I can also store the data like that:
    2013-04-04 13:20:55;93
    2013-04-04 13:25:55;94
    2013-04-04 13:30:55;95
  •  
  • I was looking for a standardized way to store the data
    At the website http://www.opengeospatial.org/ I just find standards for .xml-schemas
    I haven't found an appropriate standard for my data yet ...
    I downloaded some test-data from http://freegisdata.rtwilson.com/. They also provide .txt. files.
    So I think I will keep my .txt-File storing schema

  • For the first visualization option I am thinking of a x/y-coordination system. Where x is the timestamp and y the actual value. I haven't decided on the second visualization option yet.
  • I am not sure if I should allow to mix GIT and SVN in my solution. At the moment it is possible to load a sensor from GIT or from SVN in the system.
I appreciate every comment or help on that topic :-)
Mahalo, Tanja

5 comments:

  1. Great work Tanja. Lovely to see the UI next to the user stories - really really helpful.

    Regarding your questions, you ask "Should I store a date in my GIT/SVN .txt.-file which I display here. Or is it better to show the date, when the actuall data has been stored in the versioning system?"

    I think that a date in the txt file is probably better, since you want the precise date and time at which the recording was made, which might be different to some degree from the time that the data was added to the versioning system.

    I agree that sticking with txt format is better than XML.

    Regarding mixing git and svn, I think that is more tricky - given that you want to explore both, keep both. With no real users you have no basis to exclude one or the other.

    And while I know you are skilled in C# and using your visual studio skills makes sense, every time I see a non-web interface, my brain screams "make it a web interface" :-) It's just that a web interface makes things so much easier to share. Every non-web interface basically creates a barrier to sharing data for not much benefit in return.

    I don't mention that to say that you are doing anything wrong - we've already discussed how it makes sense for you to work with the tools you know, but in the bigger picture, if you are ever making anything where the goal is sharing, do keep in mind that almost always a web interface will make things 100 times easier ... for the end users, if not for the developers :-)

    ReplyDelete
  2. Hi Sam,
    thanks for your comment!

    Ok, I will wait for Thomas answer - but I think like you, that a date and a time in the .txt.-file and not mixing GIT and SVN will be more convenient ...

    But my software can never be used only in the web, because you always need Subversion or GIT to be installed? I currently change local files in the file system and then I push them to the remote repository ...

    ReplyDelete
  3. Actually a web interface can push things to git via javascript, and you could have a web interface running just on a local machine. But what you mention there indicates to me that you are assuming from the workflow that the scientist has the data files on their local machine and is pushing them to git/svn through this program you build.

    I had assumed that the sensor data was just going straight to git/svn from the sensors - no need to pass it through the scientists computer.

    I was imagining that the scientist has no data files on their computer - they are all in a remote git repository like github and they are browsing the files and picking and choosing which ones to visualize.

    Is there any strong reason why any of the data files should ever reside on the scientists computer, except perhaps for backup?

    It seems to me there are two functions to distinguish here. A function of pushing data to the git/svn repo, which ultimately might be installed on the sensors themselves, and the function for viewing and manipulating the data, which could be a web app that accessed all the data from a remote repository on something like github. There's no particular reason why those two functions should be combined into a single C# app is there? Clearly convenient for you, but no actual requirement for it I guess?

    ReplyDelete
  4. Hi Tanja,

    i) in regard to the XML vs. txt situation I would prefer to stay with .txt files as well.
    ii) I would not suggest to mix SVN and git. It would make more sense to me to handle them separately and compare the qualitative and quantitative aspects of both systems.
    iii) a Web interface would be nice indeed. However, this is not the focus of the work and therefore your GUI is absolutely fine. If you have later on time to spare, you could either use JS or ASP .NET
    iv) for the sake of comparison it is important that the setup (data and infrastructure) is the same for both system evaluations (SVN and git). Storing the data in the cloud is one option for an additum. Working with a local version is fine.

    I think you should head for one version of a functional prototype first. If this prototype satisfies your requirements and you did the evaluation you can take one step further in improving the system by realizing different setups or interfaces.

    ReplyDelete
  5. regarding point iii) agreed a web interface is not the focus of this work and you should not get sidetracked on that. It would be a great future project. At the risk of being controversial I'd recommend avoiding ASP.NET and using open source tools wherever possible :-) but then I'm rather biased ... I think html5 plus javascript, with some open source stack on the backend (PHP, Ruby, Python) is the best long term for stability and sharing ...

    ReplyDelete