Bug or annoyance: 4.0d RC1: Typeahead when Logos is slow often does the wrong thing

Logos is sometimes slow at populating dropdown menus, but I'm a fast typist. So I often end up getting the wrong thing when I type ahead and press Enter before Logos has had a chance to fill in the menu.

For example: I want to open my TNIV. I type (quickly) in the command bar: tniv <Enter>

I end up with a Search for tniv in my entire library. Uggh!

Or I want to do a Basic search in just ESV, so I click the "All Bibles" dropdown and type (quickly) in the find box: esv <Enter>

The dropdown closes and nothing happens. All Bibles is still selected. Uggh!

I would be quite happy if after hitting Enter, Logos did some more thinking, tried to figure out the best match for what I'd typed, and if it was an exact match, just went ahead and did what I meant. I realize that there might have been other possible choices that could have matched if I'd only waited for the dropdown to populate. But please, Logos, couldn't you implement this as a kind of "I Feel Lucky" à la Google? I usually feel unlucky after typing too fast. Logos is holding me back in my study.

Find more posts tagged with

Comments

Clinton Thomas

Or they could just improve the performance of the UI and bring it up to industry standards.

It seems to me that implementing some kind of fuzzy logic to read your mind and guess what you were trying to do would be a lot more difficult than just doing what just about every (all?) other windows application on the planet does, that is, display menu items quickly.

Sorry if this is harsh, but this is my biggest complaint about this product, its usability due to a slow UI!

Regards,

Clinton

https://community.logos.com/discussion/comment/147965#Comment_147965

I understand why they have to "recalculate" the dropdown list everytime, in the off chance that something did change, the dropdown will always be correct and up-to-date. But the way it's implemented just seems like an overkill to me. I would be willing to live with some consequences of having some of these lists cached in memory -- consequences such as:

- having to restart Logos if a new resource is added (or maybe a bubble notification in the lower right corner warning me that I have new resources added and should restart Logos for the dropdowns to refresh);

- the parallel resource dropdown being static so that they show up instantly, but with the possibility that I may click on a parallel resource that doesn't have anything to say about the particular verse I'm on, in which case I'd either get a notification message, or it would just go on to the next closest verse.

Peter

Rosie Perera

https://community.logos.com/discussion/comment/147985#Comment_147985

Or they could just improve the performance of the UI and bring it up to industry standards.

Yes, I guess I should have said that first. That would definitely be a better solution. I have been feeling more hampered by the UI sluggishness lately than ever before. Not that it's gotten worse, but my knowledge of Logos is now so much better and the majority of bugs are gone and I'm spending more time actually using it for study not just to answer people's questions on the Forum. And I'm finding it just cannot keep up with how fast I type and think. I keep being tempted to go to Google to do a search. Not because searching in Logos is all that slow (that's one of the things they've done stellar work at optimizing). But to even get to a Search panel and type in my search criteria and select the right parameters takes longer than Alt+Tabbing to Internet Explorer, clicking the Home button (I have Google as my IE home page) and doing my search there. Arggh!

- having to restart Logos if a new resource is added (or maybe a bubble notification in the lower right corner warning me that I have new resources added and should restart Logos for the dropdowns to refresh);

If they can refresh the dropdowns in just a few seconds when I click to drop them down, then surely they don't need me to restart Logos in order to refresh them. Why not refresh them during the next available user idle time after detecting that an event has occurred (new resource added, or resource newly hidden) which would change the content of the dropdowns?

JimTowler

https://community.logos.com/discussion/comment/147999#Comment_147999

If they can refresh the dropdowns in just a few seconds when I click to drop them down, then surely they don't need me to restart Logos in order to refresh them. Why not refresh them during the next available user idle time after detecting that an event has occurred (new resource added, or resource newly hidden) which would change the content of the dropdowns?

I agree!!!

There are MANY things that Logos4 could do in the background, running at low priority, so that menus, searches, prompts and all kinds of things would have snappy millisecond response times.

Lets face it: We generally have GB's of free disk, 100's of MB of free ram, and CPU power to burn. How on earth can it take so long to do some of these menu dropdowns?

Computing is about space/speed tradeoffs. Lets burn some "spare" resources to get fast UI response. Cache more stuff!!!

(P.S. And why does it take 15-45 seconds to get the application to open? My PC can open Word 2007 in about 5 seconds from cold.)

https://community.logos.com/discussion/comment/148131#Comment_148131

I agree with both of you, Rosie and Jim!

Peter

Clinton Thomas

https://community.logos.com/discussion/comment/148238#Comment_148238

I feel left out.

Rosie Perera

https://community.logos.com/discussion/comment/148254#Comment_148254

I feel left out.

I agreed with you already, Clinton, so if Peter agrees with me, then by the transitive property of agreement, he agrees with you, too. [:)] Oh my! Isn't math fun?

Ron

https://community.logos.com/discussion/comment/148131#Comment_148131

Cache more stuff!!!

+1 [Y]

I don't think I've ever seen Logos using more than a couple hundred MB of RAM (according to task manager)...some of the free resources should be more heavily utilized for caching, background calculations, etc.

Bob Soule

https://community.logos.com/discussion/comment/148307#Comment_148307

Here is an excerpt from an IBM article on the value of a responsive system as well as the link to the entire article. Although it is from 1982 it still is valid.

"When a computer and its users interact
at a pace that ensures that neither has to wait on the other,
productivity
soars, the cost of the work done on the computer tumbles, employees get
more satisfaction from their work, and its quality tends to improve. Few
online computer systems are this well balanced; few executives are aware
that such a balance is economically and technically feasible.

In fact, at one time it was
thought
that a relatively slow response, up to two seconds, was acceptable
because
the person was thinking about the next task. Research on rapid response
time now indicates that this earlier theory is not borne out by the
facts:
productivity increases in more than direct proportion to a decrease in
response time. This brief describes some of this research and the
implications
for increasing productivity and cutting costs that are among the chief
challenges of business today."

The Economic Value of Rapid
Response Time

https://community.logos.com/discussion/comment/148254#Comment_148254

I feel left out.

I agree with you too, Clinton!

Feel the love agape around here!

Peter

JimTowler

https://community.logos.com/discussion/comment/148422#Comment_148422

Here is an excerpt from an IBM article ...

Thanks Bob.

I've not read the article yet, but its open in another window, so I'll go read it next.

If clicking some menu, then needs some 2 seconds of work, before the next thing can begin/display, then where possible, begin that work in the background just in case the user wants that. If not, no harm, if yes then the work has started.

It should not be hard with the amount of ram and CPU we all now have, for an application to "learn" what a given user tends to use, and what functions they don't. Do the common ones first and cache at least a portion of the "heavy lifting", using "idle" cycles.

Rosie Perera

https://community.logos.com/discussion/comment/148622#Comment_148622

If clicking some menu, then needs some 2 seconds of work, before the next thing can begin/display, then where possible, begin that work in the background just in case the user wants that. If not, no harm, if yes then the work has started.

It should not be hard with the amount of ram and CPU we all now have, for an application to "learn" what a given user tends to use, and what functions they don't. Do the common ones first and cache at least a portion of the "heavy lifting", using "idle" cycles.

Here's another example I just reported tonight, where Print preview is really slow when the document to be printed (e.g. Search results) is long and requires some computation to generate. Logos should quickly do the work needed to show the user the first page right away and then take time during "idle" cycles to finish the rest of the work in case the user needs wants to page through it. Right now it appears they are doing all of the work up front while the user waits to see anything. This isn't a case where precaching would be a good idea, because you'd be generating a print preview every time the user went to any page of any resource as they theoretically might choose to print it; that would slow down everything.

Slabs

https://community.logos.com/discussion/comment/148624#Comment_148624

I agree completely with these posts. Why should the menus be so slow. This is the first place where you "experience" the software. I could live with searches being a bit slower, but waiting for the UI is unforgivable in my view