Link reblogged from Marco's stuff with 104 notes
Most news outlets, including TV news shows and networks, newspapers, news websites, and blogs are targeted at news junkies: they never want to miss a story, and they want to be the first to report it to you.
If you look back on these stories even one week later, the majority of them seem…
Recently I read a post by Marco Arment, one of the cool developers of this even cooler Tumblerthing, about an idea he had but couldn’t implement because of shortness of time. The idea was a different kind of news site, although news site is the wrong term. His idea was to have a site that curates the news of a week, but in hindsight. So every Sunday morning there goes up a post with the most relevant stories of the week before, the ones that have proven to have impact. This would be a way to shift through all the noise that we are exposed to today and provide us with the news that really matter. With his own words: “I want last week’s news, but only what I need to know, and only if it has proven to have relevance beyond the day it was published.[…]Don’t give me any “breaking” information or up-to-the-minute stories. Mentioning any event that happened less than 7 days ago is strictly prohibited.” I absolutely love this idea, but there are a few things that I would do differently. Depending on the niche of the site, I would expand the timeframe to a whole month. In technology that would be far too long, obviously, but with politics or health or whatever a month would be the perfect timespan to really analyze and elaborate on the things that have happened.
I am also not sure yet about what format would be used for the reporting. Would it be simply links to well written articles on the subject or would it be a weekly/monthly essay summarizing and analyzing what happened, the links only as a reference? Would self conducted interviews be appropriate or would the site profit from a more distanced point of view?
I find all of this to be very fascinating and I am inclined to give it a shot, probably even as soon as in August (yeah, I plan that far ahead).
What is even more fascinating is that I also ran across this cool article about the future of journalism and the way of semantically marking up the content so it can be used multiple times without the manual hassle that would take right now. I need to reread the article actually, because there were so many cool thoughts in there that I haven’t absorbed them all yet.
If I ever get around the “news of last week” thing, I will definitely incorporate a lot of his suggestions into the site.
Source: marco
You will recognize that the last post on this tumblog dates a while back. Let me tell you why that is. A short time after I had written my series of posts about the HealthServer I discovered something very interesting: Google already has a service very similar to what I wanted to do with the HealthServer. Of course you don’t have your data in your home and stuff, but they already offer to pull all your data into one place and make it accessible to the people that need access. In case you are wondering what the service is called: GoogleHealth. Surprise, surprise. When I saw this I was a little upset, mostly about myself, for not doing enough research on the subject. I could have talked about GoogleHealth in my posts after all and write a critique about and what not.
Then something else happened: The Facebook Privacy disaster and the advent of (the idea of) Diaspora. If you read carefully what they write about how their idea should work, you will see that most of what they propose is kind of exactly what I wanted to do in the health space. Now, I don’t claim any credit for this idea, it wasn’t mine to begin with anyways, but it made me realize one thing: Only writing about stuff is not good enough, you have to make things happen. And as I have pointed out multiple times: I fuckin can’t code.
You have no idea how frustrating it is to see cool shit happen in the world that involves the creation of code and not being able to participate in it for a lack of skill. “Stop whining, sucker, and start to learn to code” you might say, and you would be right. In fact I have already started learning Ruby on Rails to better my situation. Of course this only made one issue even more visible: my lack of knowledge and even more obvious: experience. It is really frustrating to see these guys rock the internets and the hearing that they are two years younger than you are. And yet they know so much more about this shit than I do. That is the case with people in general in the tech sphere: most of them started a lot earlier than I did (I am 20, for Christ’s sake!).
But yeah, the only thing to do about it is to stop whining and complaining and to do shit instead. So consider this rant to be over and the era of doing beginning.
I also have the intention to start blogging here more regularly, so let’s see what the future brings in this tiny little corner of the Internet.
So far I have talked mostly about the feature set and what will change if the HealthServer would come around one day. But to come around one day there has to be a business behind it that takes care of spreading the word and making people buy and use it.
As much as I love open source there has not been one major success in mainstream computing that was only backed by a community of developers and not by some sort of business venture.
The question this raises is what the possible business paths and monetization channels are. The first problem I see here is the need for the dedicated hardware. Why would I want to buy a device that has at the point of purchase exactly no additional value to me? Everything this thing would do can be accomplished by services in the cloud already. The real features that would change the world, the networking, the use at the doctors, are only possible after it has been widely adopted.
One way to forgo that could be to make it a cloud service first and only after it has been adopted move it onto the SheevaPlug. I am not sure though if anyone would agree to send their x-ray scans to some server somewhere. Not sure about that.
In the end it boils down to this: It is unlikely that the HealthServer as I have proposed it would be adopted by people early, because it would lack its most important features at this point. Since no one would have one there is no use to think about other monetization strategies like a platform model where you give developers the chance to build on top of it and share potential revenue.
Now you might think: “You sucker, you wrote so many posts about something that you know will never see the day of light!” Yeah, but that is not the point. It’s not that I woke up today and realized “shit, this is never gonna work, I have wasted my time!” No, this site’s purpose is to allow me to stretch my mental muscles and elaborate on things I think about in public.
On so I announce that next project I will talk about: Agile, a productivity app for the iphone. I have begun to learn Objective-C some days ago so this project will have a way higher likely hood of ever being real than the HealthServer.
BTW: If you want to make the HealthServer real in one way or the other, be my guest! You can have to whole concept :)
After a little break over the Easter holidays we’re back to regular programming. Today we are gouíng to briefly tackle backups. In the next week or so I will also start to talk about some other ideas I have, probably intermixed with my posts about HealthServer.
One of the main advatages of the cloud are that you don’t have to worry about backups anymore. If you have data in gmail or Dropbox you don’t need to worry about crashing hard drives or anything like that. They do this for you. What to do about it then when we are back to our own server, in our own home? We don’t want to put our files on different thumb drives, securing them off site and all that stuff, we want it to be convenient. Backing up stuff is not convenient, its a pain in the ass.
The solution to the convenience problem is this: When a lot of people use this device it could be possible to encrypt it and distibute it to other users. In practive this could mean that your health data is also saved on your friends server, but encrypted so that he can’t access it without your permission. If my device gets fried, all you have to do is to set up a new one, tell it to get your files over the net from your friends server and unpack it. É voila, you’re up and running again.
Additionally you could of course use other services to back up my data as well. The encrpted data base file could just as easily be copied to your Dropbox account or any other hosting service you might choose.
And of course you could use thumb drives.
Social Media has been all the rage over the last years and so I will talk about that briefly in context of the HealthServer.
When thinking about the social possibilities a HealthServer could have, two categories come to mind:
Let’s start with the latter.
Research is nothing more than sharing data in a predefined context. Social media is no different in that respect.
But instead of sharing where you are right now you share what your blood sugar levels are.
The beauty of this is that a widespread use of the HealthServer means an unimaginable amount of data that could be
researched and used for scientific analysis. Networks like PatientsLikeMe do this already for sick people,
but why not do it for everyone? But for everyone to do it it has to be drastically more convenient, hence the health server.
The other point of emplaying social media strategies to a HealthServer concept is the competition factor. DailyBurn does this already, but the problem with it is that not a lot of people I know are on DailyBurn. A Facebook app would do the trick, but then facebook had all my health data and I would never want that. What would also be possible is to post certain things as statuses in Facebook, which would be a lot better than giving Facebook my most private data. The coolest solution though would be to have a dashboard in my HealthServer that shows me who of my friends lifted how much weight today, how much they ate and so on. Of course under the premise that they want to share that info with me explicitely.
There are most certainly a lot of other cool things that could be done with our health data under the term of social media, but I’ll leave you with these quick thoughts.
A very important aspect of the HealthServer is how you access your information or, as I laid out earlier, how other people can access the information.
How you yourself can access this is rather trivial. The server has a web interface, so you can use SSL and securely access your info from anywhere in the world. It gets more complicated when others are to have access to it, though.
In fact there are several things that are to be considered:
Let’s take these on seperately.
Obviously you can access your info at any point in time, since it’s your data.
And you are the one who determines who else can have access. This is rather easy since if you are standing
in front of a computer you can just show someone by logging in to your data yourself what they need to know.
But especially in a doctors office this isn’t always practical and imagine you are in a critical condition.
I doubt you can remember your access details when you are under shock.
So, there has to be a better system.
What I propose is a system for identifying the legitimacy of a persons access to your data and to allow you to set up what each person is allowed to see.
In this system there are two options: personal approved setups and emergency setups.
Say you walk into a doctor’s office for the first time and you got your smartphone with you.
You talk to your doctor and she says what information she needs from you and shows you her offices HealthServer QR code.
You scan this code with your phone and define in you web interface that this ID shall have access to X,Y,Z of your personal data.
Then you give a unique address to this set-up to your doctor. When she needs access to your data she visits that link,
puts in her ID and - katsching - she can see your data.
(Note that this verification process is not very secure. I would implement some more steps and will draw you a map for what I
imagine, but this is the most basic setup.)
This setup is based on the assumption of a very widespread use of the HealthServer in homes as well as in ERs. Ain’t gonna happen, but please, don’t burst my dream bubble :)
So, imagine you are unconcious and are brought into an ER. You have a card with you with the URL to your emergency setup that you have setup at home. Here you could include your blood type, chronic deseases, allergies and the like. One way to ensure that only legitimate people access your data was to encode the URL in a QR code that only proper licensed docotrs would get. Another way would be a government database with all doctors ID publicly accessible. the doctor would enter his ID to access your data, your server would contact the database, compare the IDs and grant access or deny it based on the feedback it gets.
I am not completely sure how realistic any of the processes is I just described, but it would be cool for sure. The setups would have all kinds of variable options, so you can decide to the micro level what data any one of your docs can access. Time limits (only for 30min long sessions), if the data can be exportet (for longer use by the doctor) or else.
Over the last few posts I have outlined what I would like in a HealthServer, mainly from a homeuser standpoint. Today I want to enter a broder point in discussing what the HealthServer could do if not only the owner of the device had access to it.
Imagine for example that your doctor(s) had access to the data on the device and could store your data on it as well. Imagine all your x-rays and blood values and all the other things your various physicians have in their data sheets. Imagine giving a doctor access to all that data when you visit his office. That could provide him with a far better picture of your current health and the possible factors that are responsible.
You could not only show him your latest blood values but also how much you have slept the last days and what you have eaten. This could provide usefull indicators what causes your current illness or what you could change to get you better quicker. All with way better accuracy than is possible today.
Of course there would measuremens needed to be implemented so your doctor can only access what you wan’t him too and most importantly when you want him to. But I will touch on these issues in a later post. Today only the introduction. ;)
In my last post I said I would write about data charting, and I will.
The thing with data is that it is pretty useless if we can’t visualize it in one way or the other.
I can log as much minutiae about my eating habits as I want to, if I don’t see a chart that shows how my protein consumption
has stalled or how my calorie intake has gone down, I can’t use it.
Sure, I can read over the raw data and feel good about my geekiness, but the real value comes when I can see long term trends in a nice curve.
So what I want my HealthServer to do is to let me see my data in beautiful graphs. But not only one boring line graph after the other. No. I want to compare three or four datasets with each other, and being able to easily switch between styles and metrics. I don’t want to be hindered in any way in comparing my data. This means that if I want to compare my sleep length and depth with the growth of my toenails, I should be able to do that. I also want to annotate my data, so that when I have a sudden decrease in sleep time I can write a note that this was due to a party I attended. Even more awesome if I could annotate my alcohol consumption (or at least my blood alcohol level. There’s an app for that. :D).
The next thing I want to do is to set goals for certain metrics. I want to be able to set goals for nutritional information, e.g. a minimum and maximum for fat intake or so. Everytime I meet (or miss, this should also be configurable), my goals I want to see a message of sorts congratulating/screaming at me.
The last point I want to touch on today is the possibility of “rule sets”. It should be possible to prepare certain goals/rules, group them together and switch them on and off at will. This could mean that I can change from an Atkins diet to a primal ruleset in an instant. Concerning the evaluation of older data I want to see under what ruleset they were created and how they would meet other rules standarts. On the Atkins example again, I would see “during the period this data was entered you were on Atkins. Click here to see how it would match Sisson’s PrimalBlueprint or Weightwatchers or…”.
So much on data charting.
The previously mentioned SheevaPlug is a server running on linux.
As software running on it I would then use a simple SQL database with a nice frontend.
When I searched around the interwebs for information about databases and stuff so I could actually write something about how all of this could be built I quickly realised that I don’t know shit about databases, database models, SQL and its derivatives and all the other stuff one would need to know to write something interesting about the software.
FAIL, I guess.
But, smart as I am, I came up with a solution to lift this post out of obsoleteness.
I will simply write about what I want it to do, with focus on customizing.
See, I am not a programmer, and even if I would become one in the next year or so, I don’t want to spend nights on end
to add another metric to my data-pr0n-fest.
So, I want the final interface to provide me with the possibility to quickly add new categories, metrics,
visualiations and the like.
For example: Let’s say at one point I am able to get a blood anaylzing machine that is able to give me my daily breakdown of hemoglobin, protein, iron and what have you. Since I didn’t have this machine before and never thought I would, I need to add a new category, “bloodvalues”, containing all the different values. I then need to be able to chart this data against each other, as well as against all the data I could collect before.
Maybe all of this is trivial stuff and everyone is laughing at me now, but hell, I don’t care. Just build it for me! :) The next short entry in this little series will deal with data charting in more detail.
While I would love to have a whole bunch of servers at home and be able to geek on all possible levels, this should not be a high powered beast. While the storage capabilities should probably be around 16GB to 32GB just to be sure, I don’t need fancy processors or a lot of RAM for this. In the end this is just my health data that should be available whenever I need it, from wherever I am. This also means that it will be an always-on device, all the more reason not to choose a “real server” or an old PC to do the lifting, since they still need a considerable amount of energy.
Recently I read about a cool device named SheevaPlug that only draws 5w of power and sports a nice ARM processor, 512mb RAM and 512mb flash memory. As far as I understand it you can exchange the flash with any SD-type card to expand memory. You can run your own Linux on it and do whatever you like with it. To me this looks like a perfect fit for this kind of project. (Except the fact that I am neither a linux hacker nor can I actually code anything of value. Yeah, my life is sad.)
This should be all the hardware required to run what I want to run on it, even more so because the actual lifting it will have to do is not that great. After all I will check it maybe once a day to check my health stats and maybe compare to others and the only other use will be a doctor logging in from the hospital when I do check-ups or so.
Page 1 of 2
