Downloads: Its time for General Consensus to be considered

Andrew McKenzie said:

MJ. Smith said:

while this is not a feature I care about

You may not care, but lots of users do care otherwise they wouldn't be asking the question every time a download occurs.  Your reponse that you only want this to happen so you get your ideas voted for,  communicate a total  lack of respect for the people who do see this important and the reasons that they see it important. I am not taking up this issue soley for my wants but because it is a clear issue that a wide range of users want addressed.  I had someone contact me on facebook recently and part of that communication was that this very issue needs to be brought to the forefront of these forums.  If its not important to you, then that is fine, no one is asking for your support, but please don't disrespect ideas that are important to other people.

Andrew, I think you missed the fact that MJ has voted for this on UserVoice precisely because she cares that other people want it. She is waiting to move her votes to something else that she wants until this gets implemented for others' benefit. To me that communicates that she does care about what others want, even if it's not a feature that is particularly important to her personally. I don't normally butt in and defend others, but this time it seemed you were being really unkind without having understood what she was saying. Quoting one piece of her post out of context made it sound like she was being uncaring, when the gist of her post was the exact opposite.

Andrew McKenzie said:

You are reading something completely different to me, no where do I see her say she has voted for the idea, whether I quote one piece or the whole, and if fact the whole is there for anyone to read.   And whether not she has actually voted for it, saying she don't care about it and just wants is done, so she can get votes for her ideas is in very poor taste and adds no value to the discussion at all.

OK, I admit it. I'm inclined (perhaps to a fault) to read the best possible intentions into someone's post. Maybe I didn't do that equally with you and with Martha, so I'm sorry. Here's where I thought she was implying she'd voted for this and was waiting to free up her votes for things she really wanted: "to free the votes up for things I do care about." On second thought, perhaps you're right; maybe she was just talking about freeing other people's votes up. That honestly did not occur to me on the first reading.

Still, when she encouraged Logos to "show that they take the user voice seriously" -- she was saying she hoped that users who do want this feature get it.

I hope they do, too. It's extremely important to lots of people. I haven't voted for it either, since I've got fast Internet and don't really mind the downloads. But there seem to be enough other people who want it that Logos should pay attention to "General Consensus"  [:)] and put this on their to do list.

[source: http://magiccarrot.proboards.com/index.cgi?board=questfanart&action=display&thread=3854]

P.S. Martha also posted a big fat laughing smiley, so whatever she said was intended in good humor, not in selfishness. What I've said is also done with a genuine smile towards you, Brother Andrew.

MJ. Smith said:

Sorry Andrew but I can't resist

I believe it is General M. O. Consensus, born February 30, 1897, died in the battle of the Bottle December 32, 1928. Did I get it right?

Seriously, while this is not a feature I care about, I do think that if it is practical Logos should do it soon to free the votes up for things I do care about - and to show that they take the user voice seriously on features that do not affect the core system design..

 

MJ I sat in front of my computer for 30 minutes looking through Roman generals on wikipedia to try and make a taseful "General Consensus" joke but couldn't find the the perfect name... of course then I was distracted by the ever fascinating account of the Battle of the Teutoburg Forest.  I think you spoke for many with your light heartedness.

 

To get back on track though, I would like my Logos note taking to be taken to the next level (because I've never done a note in Logos) so whatever gets this going would be great! [A]

While, like others, this issue means little to me because of where I live I recognize that download concerns are different for those in areas with limited high speed access, or tied in to download limits. I hope that Logos is able to find and put resources to a good solution that meets the needs of these fellow Logos Lovers that builds upon how things are currently down. Personally I want to be able to blissfully download my updates in the background without caring about what is going on. However I would be willing to give up a little bliss if it aides others. If you want to know how much bliss I would be willing to give up you will have to ask the General.

Thanks Bob,

Bob Pritchett said:

benefiting only a small number of users who fall into one of two camps: 1) the "I want to know every detail" group (small, but passionate)

That'd be me.  But there is another reason I want to know what books/resources/program updates are downloading - and that's because people are asking and I have to answer.  For that - we've developed the wiki page: An update is downloading, what is it .  Even as a details guy I simply want to know that a download is bringing books or program updates.  I've now got enough experience that I know generally what it is and lacking a download cap at the moment I've not cared beyond the someone neurotic need to know, even if I'm going to click OK anyway.

Bob Pritchett said:

and 2) the "I have limited bandwidth" group (also small, and to whom I'm sympathetic, but for whom this doesn't seem to help much, since in the end you still have to choose all/nothing about upgrading at this point, which you can already do by turning off auto updates and looking at the "new release" posts).

Being a member of Group one, I frankly don't really care about my type.  Generally the ones that are frantic enough to know which DLL's are being replaced have the skills already to figure it out.  (me).  IMHO it's this second group which needs the information.  

Yes it's not simple, and yes they are eventually going to click the OK box anyways; but there is a bit of mental staging that happens when you're at the end of a month's budget and you have to determine whether or not you want that ice cream cone with your family or gasoline in the tank so you can go to work in the morning.  I choose the gasoline every time.   

Ok, ignore my analogy it breaks down too easily.  But when it comes to budgeting bits I'd rather that those who need to so so have the capacity to do so.  

Seeing the complexity involved even on this small level  - I say ignore my desire for an thorough description of the bits.  But in the least assign one person to write a brief description of every update and post it somewhere where it appears on the home page of the program and duplicate a copy in the forum.    I realize that not everyone reads the forum, and not everyone reads the home page (guilty) but at least then you can say, "that information is consistently available at this location."

 

Thank you for responding, Bob.

Bob Pritchett said:

The "last modified" date column in the Library view is the easy one; the complication is probably that we have to extend some data structures, will need to recreate some files on your system, test the code, etc. It hasn't been a high priority, compared to 4.1 and even 4.2, but we can move it up now that those things are almost done and almost done.

Good. That would be useful.

Bob Pritchett said:

So the only question is, "Do I want this now?" And that questions seems to be 100% about your bandwidth; because if bandwidth is not an issue, then the answer should always be yes. And if bandwidth is an issue, then make the decision based on your bandwidth scheduling. If there's anything so big/important/urgent that you would blow past your bandwidth caps to get it, that information will be readily available in a blog post, forum post, release notes, etc. that you can consult before turning updates on.

Yes, the issue is bandwidth. The problem is, people can't make that decision without the knowledge of how big the download that is coming is. Right now Logos just tells them there is something new. It could be just a help file update or a single pre-pub that shipped, or it might include new versions of Biblical People/Places/Things databases which will be enormous. There is generally not an announcement on the forum when BP/P/T are being updated. MVPs are usually taken by surprise with that, too. Not that we mind. Most of us have unlimited bandwidth. But we end up taking all the questions from people who are upset by the surprise.

Bob Pritchett said:

We're an organization of around 200 people. I don't want to say that we don't know what we're doing, but it is true that we don't all know what everyone's doing. This is, of course, a fixable problem. We can create tools, procedures, and other bureaucratic overhead that ensures that all this information is channeled appropriately. And more slowly.

1) When books are updated, they are put in a staging directory by the text team. They arrive as book files, which can be read by the Logos code on your hard drive. In simplistic terms (i admit, I don't even know the details myself!) they sit in an FTP directory. Your system asks if there are newer book files; there are, they're downloaded, and then the code on your machine can open and parse them and read out the metadata.  There's no place in this process for "why it was updated" to be recorded. That text team obviously knows, and sometimes even collects that info into a wiki page or email, but this is an informal process. And there are multiple text teams, some doing maintenance, some building new books, etc.

To tell you what books are there, and what's been updated, we'll need to a) write code to "open and read" the book files on the server. b) Build some sort of message/description storage database on the server to record "Spelling errors and typos corrected." or whatever the message is, and then to serve that to you. c) We'll need to write code on the client side to download these messages and file metadata, present it to you in a non-interruptive way, and only then download/not download it.

2) When the code is updated, by any of 20+ people working on it, a comment is attached to every "code checkin." This list of "what happened in this release" can be hundreds of lines long. So the teams maintain a more abstract list of "what's new in this release", which you eventually see in a forum or blog post. But to show this to you at the time of download, we'll need to maintain it more formally, store and serve it from a server, build a place in the UI to show it to you, etc.

 

Bob, with all due respect, you are shooting at a straw man. People are asking for L4 to bring back what L3 offered (minus the ability to selectively choose which files to download). That means just a list of what files will be downloaded and their sizes, and the new version number if it's a program update, not comments about what has changed in each file. This does not mean a massive change to add in bureaucratic overhead.

From an MVPs perspective, yes it is easy for me and power users to know where to find info in the blog, forum, release notes, email about pre-pubs shipping, etc. about what new files are going to be downloading. But it's all over the place, and most users don't know to look for that stuff, or they don't go looking until it's too late and they're irritated that they have to look for it rather than the info (filenames/sizes) being fed to them within the software as it was in L3.

Logos has been inconsistent in the past about posting lists when major new resource updates are coming. Even when Melissa does post a nice long list of resources that are about to be uploaded (which people do very much appreciate -- it gives the necessary info: filenames/sizes), most people don't see those posts. As you know the volume of posts on the forum is staggering, and even I who spend nearly all day on the forums can't keep up with them all. We MVPs get asked repeatedly what is this huge download and have to point people to the forum post, by which time it's too late for them to halt the download. And people want to know what it is even when it's just a couple of files. I can't tell you how many times someone has asked "what was that download" and we MVPs have had to research it in our own Resource folders and answered back "it was just a new version of the Help file." They were satisfied. That's all they want to know. "What is it?" Not "Why?"

If Logos is going to be downloading a list of files from the FTP server, it has to know what that list of files is in advance. Just show it to people on the screen so they can decide "yes, I want it now, it's less than what I have left in my download cap for this month" or "no, I'm going to have to wait until Nov 1" or "wow, it's got that pre-pub I've been waiting for in it, so I guess I'm willing to bite the bullet and pay extra to go over my download limit for this month." Simple as that. Don't make it into something bigger than what people have been asking for. Maybe it's a tease, and maybe they'll be disappointed to have to wait, but they're disappointed now at getting a big fat surprise when it turns out to be something huge they weren't expecting.

Bob Pritchett said:

And -- confession time, again -- I can't believe that if we go to all this trouble, we won't immediately be hit with a request to "let me download THIS book, but not THAT book," which is logistically even more of a nightmare.

Quite possibly true, but your reason for saying "no" to that request still holds and is valid. You can continue to say no, and we MVPs will support you in that.

MJ. Smith said:

I think the people with genuine problems (as opposed to those who just want to know) should be satisfied with a very simple list:

• software update - version and size
• resource update - titles and total size of the resource update

What I think those of us with fast service and no caps are missing is:

• if downloading noticeably slows my machine, I may wish to delay downloading until AFTER I have finished tonight's Bible study handout
• if I have a cap it is usually set for a particular length of time, usually a month. I may wish to delay the downloading to the first of next month - or if the resource is critical I may wish to budget for exceeding the cap

I think these two issues should be addressed with fairly high priority.

I do agree that the minimal info you mention would be enough for me.  If the update is something I don't find urgent, but is big, I might choose to delay it to the end of the month and beginning of the next (I've had a 5 day update!!).  So it helps to know how big it is.  BITS does not work on my ISP, so I,ve been blocked from email etc internet access for days on end while downloading.  Dave did very kindly offer to make me a fix for that, but I was apprehensive about meddling with the registry.

I'd also appreciate the option of  downloading new resources, usually smallish, before mammoth updates.  I realise I'm one of a tiny minority, but these multi-GIG updates are a mammoth problem for me.  I have appreciated the last small updates.

I think a message on homepage, possibly with a link to the wiki page, or at least its address, would be a great help.  Preferably at least a day or 2 before the update.  The last update had started on my computer before the (much appreciated) post appeared on the forum.

I'd also  make a plea that we try to be  less combative in the forums, this one included.  

I was happy to see that update notification is at last under consideration.  As I think it was request no 3 in number of votes in Uservoice today, I would hope that Logos will listen to the voice of its users on this point [;)]