Bug - Leaky Reading Plan

Mike Binks said:

I have the M'Chayne reading plan and commentary set up in a layout of its own.

Mike Binks said:

surely the Reading Plan Prompt shouldn't appear here? 

Sure it should... at least with how reading plans currently work. They are tied to the resource, not to a layout... just as note & highlight documents are. If you have the reading plan turned on in your Bible, it will appear in ANY layout which has that bible resource. If you turn it off, it will be turned OFF in any layout... including the layout which you have chosen to use as your "reading plan" layout.

This is one of the issues which should be fixed with a reworking of "layouts." But I don't have time to digress tonight. [;)]

alabama24 said:

Mike Binks said:

I have the M'Chayne reading plan and commentary set up in a layout of its own.

Mike Binks said:

surely the Reading Plan Prompt shouldn't appear here? 

Sure it should... at least with how reading plans currently work. They are tied to the resource, not to a layout... just as note & highlight documents are. If you have the reading plan turned on in your Bible, it will appear in ANY layout which has that bible resource. If you turn it off, it will be turned OFF in any layout... including the layout which you have chosen to use as your "reading plan" layout.

This is one of the issues which should be fixed with a reworking of "layouts." But I don't have time to digress tonight.

But why do you think this is an "issue" that needs fixing? If something is due on the Reading Plan, it shows. I'm with Dave on this one. If the Reading Plan info is somewhat in the way, one may turn it off in the 'increasingly inaccurately named' Visual Filter menu:

NB.Mick said:

But why do you think this is an "issue" that needs fixing? If something is due on the Reading Plan, it shows. I'm with Dave on this one. If the Reading Plan info is somewhat in the way, one may turn it off in the 'increasingly inaccurately named' Visual Filter menu:

Scrap all you know about Logos for a minute and play along with me. 

1. The term "layout" implies the arrangement of shapes "laid out" to form a pattern. 
2. In a computer program, a layout will be limited by the size and shape of the computer monitor (Among other things)
3. Many users have multiple computers, with different sized and shaped screens. 
4. It may be preferable to users to have unique layouts for each device. 
5. Layouts may also be shaped based upon the function of the task at hand. 
6. Many users have a need or desire to create and use layouts for specific tasks or projects. 
7. It is desirable for resources to maintain their preferences based upon the specific project or task at hand. For example, a user may want Faithlife community notes opened to study a passage for a small group meeting, but not for his thesis project. 

Here are some of my ideas based upon the previous observations:

1. The term "layout" should be reserved for templates created for the arrangements of panels and tools. 
2. A new feature called "projects" should be implemented. 
3. A user may have a "project" each of many tasks including: Sunday morning sermons (as many project files as needed for current and future sermon prep); small group prep; events (weddings, funerals, etc); devotional; school work, etc.
4.  A "project" would honor resource preferences for the task at hand. One's reading plan visual filter would not need to be visible in any other project than ones reading plan one. 

An added benefit: Reading sync could easily be understood on mobile. Currently, mobile sync of locations is trying at best. If a user has book "x" open on mobile, it will stay put no matter what. A user can't move between mobile & desktop and have the sync of locations without going through a cultic ritual. I suggest having projects be selectable on mobile. When a user wants to pick up on sermon prep, he can load the project file of his choice. All resources would then open to the location last used in that project.

What say you?

Dave Hooton said:

alabama24 said:

• A new feature called "projects" should be implemented.

I agree. Welcome to Logos 6!

Ugh. I hope not, but you are probably right. 

I have been thinking about creating a "meta suggestion" thread outlying more clearly and systematically why I want the changes I want. If I dawdle too much, L7 will be here. I've been thinking about this for at least a year. [:P]

NB.Mick said:

the relation between projects and layouts may be difficult to design.

A "project" relates to open resources and searches, and run guides. A layout is the shape and placement of those elements. A "project" is opened in the context of a "layout." A project, however, may be opened in more than one "layout"... especially when more than one computer or device is involved. On my MacBook, for example, I like to have 4/5 of the width of my screen taken up by two, equal sized panels. The remainder (1/5) is a "tools" panel (i.e. where I have my highlighting panel). That layout is ridiculous on my 21.5 iMac. I can only imagine how bad it would be on the large iMac screen! [:S]

NB.Mick said:

But it is a difficult question which book belongs to which project.

You aren't thinking like someone with an ebook library should be thinking. A book can belong to every project! Each project would keep tabs on the location and settings independent of all others. 

NB.Mick said:

You seem to imply above that a reading plan is a project in itself - I would see it as a potential part of a project. But then reading plans are intended to work in fixed time intervals (such as daily), regardless of whether the user opens his project on that day.

Some people would create one project for all reading plans. Others might create a project for each reading plan. There is no reason, however, that a user would have to create a project for reading plans. As you pointed out earlier, a reading plan is shown visually through the visual filter menu. [A user could choose to have the resource with reading plan activated in a number of "projects." This behavior would be equivalent to the status quo. The resource location would remain in place (for that project) except the one you were actually using.]

NB.Mick said:

Somehow I think your idea may nor fare that much better in the area of mobile sync. Guess I open the NIV on my Kindle Fire and Logos needs to ask me "which instance of it - the one in Project A, B, or C" (which all would open it to a different verse where I had looked at it on the laptop).

No. The mobile device should have three choices:

1. Open to a default "mobile" project. Note: this is exactly the status quo now. This is exactly how the mobile app works (at least iOS).
2. Open to a user specified project. A user could choose, for example, to open to his or her "devotional/reading plan" project.
3. Open to the "last used" project. 

NB.Mick said:

And I think with bibles it breaks down, since users will mess it up: With different projects on their desk/mind they will tend to scroll in their bible even if the instance they have open belongs to another project. And they won't want to download several instances of the same book onto their device - which in turn will mess up the "last read" position for the project after it had synched up. 

This potentially becomes a problem with #3, but not so much with #1 or #2. Buyer beware. 

Out of friendly curiosity: What is your suggestion for fixing the shoddy sync that currently exists?