25.0.0-alpha2: Allow to further drag the feedview list (and/or provide alternative view)

[tgurr]

IMPORTANT

Read and tick the following checkbox after you have created the issue or place an x inside the brackets ;)

• I have read the CONTRIBUTING.md and followed the provided tips
• I accept that the issue will be closed without comment if I do not check here
• I accept that the issue will be closed without comment if I do not fill out all items in the issue template.

Explain the Problem

In 25.0.0-alpha2 there appears to exist a maximum I'm able to drag/extend the feedview list cutting of the text of longer headlines which makes them impossible to read. My personal workflow is that I skim through the list and often don't even click any article for details so the huge white "Kein Artikel ausgewähl" space on the right side is most of the time wasted space for me. An alternative view would be to just show the right pane if an article is clicked and/or to allow it to be toggled somewhere and/or moved below (think of how Microsoft Outlook has it's certain most common default views for mails and previews) but that may be out of scope for this bugreport.

Steps to Reproduce

1. Drag/Extend the feedview list more to the right
2. Reach a certain maximum (which is not enough)

System Information

• News app version: 25.0.0-alpha2
• Nextcloud version: 28.0.0
• Cron type: system cron
• PHP version: 8.1
• Database and version: 10.6
• Browser and version: Chrome latest
• OS and version: Linux 6.6.7

Contents of nextcloud/data/nextcloud.log

Paste output here

Contents of Browser Error Console

Read http://ggnome.com/wiki/Using_The_Browser_Error_Console if you are unsure what to put here

Paste output here

[ManuelSailer]

My workflow is similar to @tgurr's . I use the news app to browse through lots of news articles from many feeds. When I want to read an article I open it in a separate browser tab by clicking on the icon on the left. Therefor I have no use for the details pane at all.
To fit the UI to my needs I applied the following user styles which could be added to the app as a second view:

/* Hide details pane and splitter */ 
.splitpanes__splitter,
.splitpanes__pane-details {
    display: none;
}
.splitpanes__pane-list {
    width: 100% !important;
}
/* Top align icon and buttons */
.feed-item-row .link-container,
.feed-item-row .button-container {
    align-self: start;
}
/* Expand main container to keep buttons at the right also with intro texts shorter than one full line */
.feed-item-row .main-container {
    flex-grow: 1;
}
/* Allow intro container height fit to intro text length */
.feed-item-row .intro-container {
    height: inherit;
}

And I am quite happy with this result:

[powerpaul17]

I can understand your workflow but the 3-pane layout is recommended in the NC design guidelines. Also in my opinion the list looks a bit weird if you have a broader screen (in your image it's fine).

A possible solution would be to limit the list width like the article view and close the article view if there is nothing selected.

[powerpaul17]

Regarding the maximum drag width: this should be configurable in the component if I'm not mistaken.

[powerpaul17]

Something like this for example:

[ManuelSailer]

Improved user styles to limit intro text length to 3 lines as some feeds, e. g. https://netzpolitik.org/feed/, contain very long intro texts (full article?).

/* Fit intro container size to intro text length, but limit intro text to 3 lines */
.feed-item-row .intro-container {
    height: inherit;
    -webkit-line-clamp: 3;
    -webkit-box-orient: vertical;
    display: -webkit-box;
}

[ManuelSailer]

Even on wide screens I prefer to display the article list in full width:

I rarely use the buttons on the right. And if I want to use them the grey background of the current article gives me enough orientation to find the right buttons quickly.

But please implement it according to the NC design guidelines. If someone prefers something different, he/she can achieve this by applying user styles.

[mmehnert]

Is it also possible to somehow reproduce the automatic marking of articles as "read" once scrolling past them? That in combination with the userstyles posted above would make the interface really usable again.