Downloads: Its time for General Consensus to be considered

In another recent thread on the issue of why things are done the way they are with notes a comment was raised that Bob Pritchett has previously mentioned in a question about notes:

We changed the way notes on right-click
worked because of a general consensus in user interface design that
"cascading fly-out menus" are a bad idea. (They take too much precision
mouse movement, are too easy to "fall off of", etc.)

I asked the queston: who is exactly is "General Consensus" ?

Investigating this question further I find he also pops-up on the issue of the download management fiasco that currently exists in Logos 4, most typically posing the question, "What was in last nights download?".

Long-suffering users have asked, and user-voiced, for a solution, in two parts

1) A download manifest, including the size of the download before a download is started

- Why: So users can determine if right now is the appropriate time for them to be doing the download. A very good reason for this is they might live in a country where they have a monthly cap on their downloads

2) When the download involves resources, and the download has been completed, their should be a date column available in library browser that can be sorted on to see the most recently added resources - both new and updated - so essentially the date the current file downloaded.

If "General Consensus" is being used by Logos as the go to man for making decisions on the work flow of our personal bible study, can you also please make use of "General Consensus" on the download issue as he seems to be very active on these forums on the topic of better management of downloads. And not only on the forums but also UserVoice

As the suggestion says, this is nothing new, its a missing feature from Logos (Libronix) 3. In fact as it stands it is number 3 on the list of top ideas, with the top idea already planned (bring back PBB) and idea number 2 (code performance/optimisation) already being started.

(You can add your vote here.)

So how about it Logos, even "General Consensus" wants to see something done about this missing feature in the software. Would you please listen to him on this issue as you apparently have on other issues.

Find more posts tagged with

Comments

MJ. Smith

who is exactly is "General Consensus" ?

Sorry Andrew but I can't resist [:D]

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..

Simon’s Brother

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.

Rosie Perera

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.

Simon’s Brother

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.

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.

Paul N

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]

MJ. Smith

communicate a total lack of respect for the people who do see this important

My apologies - I didn't intend to sound disrespectful. I meant to imply support for doing a feature I don't care about before features I do care about because of the solid support behind it.

Simon’s Brother

communicate a total lack of respect for the people who do see this important

My apologies - I didn't intend to sound disrespectful. I meant to imply support for doing a feature I don't care about before features I do care about because of the solid support behind it.

Apology accepted.

Bob Pritchett

I agree, it appears there is consensus that this feature is desired: knowing what's in the update, and knowing when a book was last downloaded/updated.

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.

I confess, I still have a hard time seeing the point of the "what's in this download" feature. I'm not saying we won't do it, but I want to make one more explanation of why it's truly useless, and your (collective, I'll admit) insistence on it will simply waste time and delay new features and bug fixes.

A) For reasons already explained to death, we can not support partial updates. It's all or nothing, including resources and code, which are tightly coupled.

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.

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.

We presently automatically download updates in the background using BITS (on Windows), and then tell you about the update in a limited-to-160 character message bubble on the system tray. BITS has the nice feature of using background bandwidth and downloading over time, so you never have to say "Yes, update me." and then realize it's going to take 3 days. BITS doesn't tell you until it's already got it, even if it took weeks of sporadic short bursts.

Telling you what's in the download and then getting download permission means we'll be "teasing" people with the new download, then having them wait hours (days, on dialup?) to actually get it, and which point we have to interrupt them again to get permission to do the install.

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.

Yes, we can do all this. But it is not simple and, at least how I see it, will result in more process overhead at Logos, making us less efficient, more interruptive messages in the UI, confusing more users, and a lot of telling 98% of our users details they don't care about, since they can't do anything except accept/reject the whole download.

I just see the whole thing creating more support hassles and more confusion, and 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), 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).

-- Bob

TCBlack

Thanks Bob,

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.

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."

(‾◡◝)

For me, the only thing I really care about is a "Last Update" column for the resources in the Library view and a concise note about program updates that can be read in the Wiki, on the forums, by email, whatever and wherever.

I appreciate Bob's concern about growing the overhead by larding up the thoughput (and for minimal gain/return). One of the inherent strengths in a small company is the ability to maneuver quickly as opposed to mega-corporations which maneuver very slowly and always seem to have people devoted to the perpetuation and growth of the bureaucracy. Reminds me of Dickens' "Circumlocution Office" in Little Dorrit.

Rosie Perera

Thank you for responding, Bob.

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.

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.

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.

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.