Clark will continue to use red:
General comment: My reason for putting writing this stuff up and putting it into a spreadsheet is that it seemed like a necessary step to make progress and it wasn't getting done. So my goal is to provoke someone with the requisite systems knowledge to write out usable specifications, and when that happens I am happy to be wrong about any of this.
On Tue, Jul 20, 2010 at 10:09 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:Scott's new comments are in green. I've only made comments where I felt additional discussion is warranted.First, I think we need to clarify how potential readers will download the widget. I expect the actual downloading will occur over a distributed network, however, Im unclear as to what exactly will initiate this process. I see that there is a function within the reader widget to copy the software, but how does someone without this widget initiate the download? My thinking was that any time a reader sees a PM widget on a web page, he/she can activate the reader features on that widget, get lists of posts and if he/she likes what the widget does, he/she can copy it to his/her own PC. This is why I ended up having only one widget (we had at some point talked about having separate ones for readers and bloggers). The widget that appears on blogger websites needs to be the source for the reader's widget, since there will be no central server. If all of the reader functions are accessible via the Blogger's website, then what is the incentive for a reader to download the widget other than the convenience of not having to go to a Blogger's site? Also, the Project PM site in theory could host a single widget that readers can then access to obtain all of the reader functions. One thing I am trying to do is adhere to a certain concept of Project PM (that I carried away, hopefully not erroneously, from my first conversation about the project) which I thought (having been thereby somewhat liberated from my conventional notions) was appealing in its parasitic simplicity: no website, no server, no costs. Ultimately, if Project PM is successful, traffic to a server would mean somebody has to bear the cost of the hardware, maintenance, internet connection and bandwidth, and also be a webmaster. I am guessing that if the website just contains informational text and graphics, that a host might carry it for free, but if thousands of visitors come there to download software, I suspect we may be looking at probably small, but annoying and unending, costs and administration. So, if it is possible to get a widget directly from another widget, and perhaps even put the background information (FAQ's, founder's bio and tips on how to roll your own) in a pop up out of the widget, I am not in favor of a home page. To step back a little, what got my attention about Project PM was that there's all this electronic infrastructure and beyond-vast world of information out there, and here's this simple to use and cost-free tool to potentiate the best of the information. So I hate to encumber the concept.
Also, do we need to add that when downloading, there should be a check to make sure the most recent version is downloaded? I don't know how software updates work in a serverless network, but I was assuming it would necessarily be automatic, that is, "your" widget will pick the update up from finding and interfacing with other widgets, like all the other information in network, so the updates would be sort of viral. I'm confident this can easily be done by someone with knowledge in the space. I'd like to believe though that there must be an initial site where new software is uploaded. Hosting a single widget on the Project PM site may serve this purpose. I don't understand this aspect enough to comment further. But I'm anti-website.
Third, and I dont find this to be pertinent to the purpose of the spreadsheet but would like to get the thought down on paper before I forget it. Is it better to use time or a time frame (i.e. within 24 hours, within 72 hours, more than 3 days old, etc.)? In the current setup, a hypothetical reader could log in at 12:01am and see zero posts while there may have been several written in the previous hour. I considered this question, exactly as you articulate it actually, and I felt that the time frame (24 hrs, etc) would be more desirable than the midnight cut-off. Nevertheless I set it up the way I did to avoid the request triggering a separate search and calculate operation for every request; this way the network can use a set of continually adjusting lists, one for each combination push/lookback-time selections, and not have to calculate and search anew for every reader request, but just find the current list and update it with new posts since the last query. My understanding from reading about serverless networks was that although it is more efficient to transfer information directly user-to-user, as opposed to going to a server and back out to another user, serverless networks require more or less continuous traffic among the users for updating and exchange of data, and some internet service providers may block them for purposes of economy and control. This is definitely something that warrants investigation. I don't see why there should be a difference between lists such as posts since 12:00 AM EST and lists such as posts in the past 24 hours. In the former, it may be possible to use time since posting to determine proper listing, with this list being updated continuously. If you query for material in the last 24 hours, the system has to calculate when that period began (no big deal), and then perform a new search starting at that time (while the hourglass flickers), but if the search is from a standardized time, the system just has to update an existing list. What I would say to the programmer is that the 24 hour query is obviously better, but if that is going to be slow or have other negative effects, consider a menu of less flexible options.
As an aside, is there a reason a reader cannot see posts made more than 5 days ago? I was just trying to limit the transmission of cumbersome amounts of data, and I am looking at this as what's-happening tool rather than a research tool or an archival index. So it was an arbitrary cut-off, could be longer. But seemed to me there needed to be controls on the amount of data searched-for and returned. You make an excellent point about the load on the network, and I have on idea what the answer should be but as a reader I would find it annoying if I was away for several days and upon my return I missed a very popular post because I was a day late. Something that I just contemplated which is a negative is that with an unlimited time span links to posts may become stale and no longer active. No disagreement here, so what should the lookback/dropoff period be?Will readers be able to suggest a post to an existing reader and/or non-existing reader, which could improve information flow and readership? Same answer, I thought about this but did not include any reader-to-reader sharing/communication features since they exist elsewhere and I wanted to limit burden and complexity of the network. While not necessary and increasingly abundant on various sites as you've mentioned, I think there's good reason for the spread of this concept and that it's important for readers to have the ability to pass along suggestions. This is not only a tool to increase readership but it could have the secondary effect of bringing intelligent minds into the fold. No disagreement at all here; these are desirable objectives. I would encourage you to describe them as functions and add them to the spreadsheet, I can not at the moment think of a simple way to build in these features. We should describe what we want and let the programmer tell us what's feasible.
Will readers have the ability to provide any feedback to a posts merits such as thumbs down or up? I considered this and decided not to include features that already exist in other systems, like reddit, or even Facebook. In this case I am not sure where the feed back would go, to all PM widget-holders? To the author of the post? My compromise was to include a reader popularity feature in terms of counting views, as a possibility, but again I was being conservative about what we ask the network to do, in terms of burden of data transfer and storage (which will be associated with each widget, not central). While being able to provide feedback to writers as to popularity amongst readers would be a nice feature, you're right that maybe this is not feasible.
On Tue, Jul 20, 2010 at 6:10 AM, Clark Robinson <robinsonchicago@gmail.com> wrote:
Hey Scott, thanks, this is incredibly useful. Forces examination of assumptions.
Barrett you may want to pass this stuff on to Tarn or Toady or whoever else is looking at the widget specs.
Black = Scott
Red = CR
First, I think we need to clarify how potential readers will download the widget. I expect the actual downloading will occur over a distributed network, however, Im unclear as to what exactly will initiate this process. I see that there is a function within the reader widget to copy the software, but how does someone without this widget initiate the download? My thinking was that any time a reader sees a PM widget on a web page, he/she can activate the reader features on that widget, get lists of posts and if he/she likes what the widget does, he/she can copy it to his/her own PC. This is why I ended up having only one widget (we had at some point talked about having separate ones for readers and bloggers). The widget that appears on blogger websites needs to be the source for the reader's widget, since there will be no central server. Also, do we need to add that when downloading, there should be a check to make sure the most recent version is downloaded? I don't know how software updates work in a serverless network, but I was assuming it would necessarily be automatic, that is, "your" widget will pick the update up from finding and interfacing with other widgets, like all the other information in network, so the updates would be sort of viral.
Second, the following statement confuses me: Drop-down appears with two questions permitting selection by radio buttons. Can radio buttons be a selection within a drop-down menu? Good point, terminology in spreadsheet is probably wrong. I thought radio buttons are the small circles next to possible selections and whereby only one option can be selected. My intent was for there two be two sets of selectable options, need to make one selection in each, two sets of radio buttons or whatever the little dealihoozles should be called. Also, can I view all posts with more than 5 pushes while ignoring time, or do both options need to be selected for the list of posts to be displayed? I thought about this same question, and concluded that both selections must be made, because after the network has been up for a while, a request for all posts with more than X pushes would return too long a list. Although if it is felt that a longer "look-back" period is desirable, that's just a matter of changing the values in the options.
Third, and I dont find this to be pertinent to the purpose of the spreadsheet but would like to get the thought down on paper before I forget it. Is it better to use time or a time frame (i.e. within 24 hours, within 72 hours, more than 3 days old, etc.)? In the current setup, a hypothetical reader could log in at 12:01am and see zero posts while there may have been several written in the previous hour. I considered this question, exactly as you articulate it actually, and I felt that the time frame (24 hrs, etc) would be more desirable than the midnight cut-off. Nevertheless I set it up the way I did to avoid the request triggering a separate search and calculate operation for every request; this way the network can use a set of continually adjusting lists, one for each combination push/lookback-time selections, and not have to calculate and search anew for every reader request, but just find the current list and update it with new posts since the last query. My understanding from reading about serverless networks was that although it is more efficient to transfer information directly user-to-user, as opposed to going to a server and back out to another user, serverless networks require more or less continuous traffic among the users for updating and exchange of data, and some internet service providers may block them for purposes of economy and control. Also, I expect by using time frame instead, it will alleviate issues that could arise as a result of different time zones. Good point, not sure what the solution is. As an aside, is there a reason a reader cannot see posts made more than 5 days ago? I was just trying to limit the transmission of cumbersome amounts of data, and I am looking at this as what's-happening tool rather than a research tool or an archival index. So it was an arbitrary cut-off, could be longer. But seemed to me there needed to be controls on the amount of data searched-for and returned.
Finally, a few questions I have. Will readers have the capacity to alter defaults There are a couple of preselections and it would make sense to me if a reader could re-set those so he/she does not have to re-enter their customary choices every time, but since they're just default selections different selections can be made for every search. i.e. display order for links Probably would be no big deal to add this, but would mean another menu must appear, time period/frame, and number of pushes I set it up with a limited number of choices for the reason described above, to reduce the burden on the network of searching and calculating anew for every query ? Will readers have the ability to provide any feedback to a posts merits such as thumbs down or up? I considered this and decided not to include features that already exist in other systems, like reddit, or even Facebook. In this case I am not sure where the feed back would go, to all PM widget-holders? To the author of the post? My compromise was to include a reader popularity feature in terms of counting views, as a possibility, but again I was being conservative about what we ask the network to do, in terms of burden of data transfer and storage (which will be associated with each widget, not central). Will readers be able to suggest a post to an existing reader and/or non-existing reader, which could improve information flow and readership? Same answer, I thought about this but did not include any reader-to-reader sharing/communication features since they exist elsewhere and I wanted to limit burden and complexity of the network.
I also had fun just now contemplating the concept of a non-existing reader; not sure at first what that meant, but then I remembered that I wrote some term papers for them back in the college dorm.
On Tue, Jul 20, 2010 at 12:55 AM, Scott Mintz <scott.w.mintz@gmail.com> wrote:
The following relates to the READER section of the spreadsheet. Tomorrow I will write something up on the BLOGGER section.
First, I think we need to clarify how potential readers will download the widget. I expect the actual downloading will occur over a distributed network, however, Im unclear as to what exactly will initiate this process. I see that there is a function within the reader widget to copy the software, but how does someone without this widget initiate the download? Also, do we need to add that when downloading, there should be a check to make sure the most recent version is downloaded?
Second, the following statement confuses me: Drop-down appears with two questions permitting selection by radio buttons. Can radio buttons be a selection within a drop-down menu? I thought radio buttons are the small circles next to possible selections and whereby only one option can be selected. Also, can I view all posts with more than 5 pushes while ignoring time, or do both options need to be selected for the list of posts to be displayed?
Third, and I dont find this to be pertinent to the purpose of the spreadsheet but would like to get the thought down on paper before I forget it. Is it better to use time or a time frame (i.e. within 24 hours, within 72 hours, more than 3 days old, etc.)? In the current setup, a hypothetical reader could log in at 12:01am and see zero posts while there may have been several written in the previous hour. Also, I expect by using time frame instead, it will alleviate issues that could arise as a result of different time zones. As an aside, is there a reason a reader cannot see posts made more than 5 days ago?
Finally, a few questions I have. Will readers have the capacity to alter defaults i.e. display order for links, time period/frame, and number of pushes? Will readers have the ability to provide any feedback to a posts merits such as thumbs down or up? Will readers be able to suggest a post to an existing reader and/or non-existing reader, which could improve information flow and readership?
On Sun, Jul 18, 2010 at 5:40 PM, <robinsonchicago@gmail.com> wrote:
I've shared Widget functional description Message from robinsonchicago@gmail.com:Click to open:
Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations.
