For the capability matrix, part of the problem is that the rows don't all make that much sense, as we've discussed a couple times.
But assuming we keep the content identical, maybe we could just have the collapsed view and make the table selectable where *just* the selected cell controls content below? You won't be able to do side-by-side comparisons of the full text of things, but you will be able to keep the overview and drill in one at a time quickly. Just one idea. A couple ways to save space without rearchitecting it: - Apache Hadoop MapReduce and JStorm can be removed as they are on branches, not released. - I think we can also remove rows that are not started or not complete in the Beam Model, and remove the Beam Model column. - I think Splittable DoFn really just deserves one row for bounded, one for unbounded, and any caveats go in the details. - All the windowing rows can be condensed into "Basic windowing support" and "Merging windowing support" and any runner that can only run a couple WindowFns can have details in the caveats. At this point any runner that doesn't do Windowing by invoking a user's WindowFn simply doesn't really support windowing in the model. - "Configurable triggering" can absorb "Event-time triggers", "Processing-time triggers", "Count triggers", and "Composite triggers". Same. At this point any runner that doesn't support the whole triggering language doesn't really support triggers fully. Kenn On Mon, Dec 14, 2020 at 7:39 PM Griselda Cuevas <g...@apache.org> wrote: > Hi folks, another page that's getting a refresh this time around is the > Capability Matrix, which is one of the most critical pages for users as > they evaluate the current support for each of the Beam runners. > > The situation we'd like to get your input on is: How do we optimize the > expanded version of the capability matrix, which explains the level of > support in each of the functions? > > Right now the text gets in the way of analyzing the table and makes > reading hard. You can see a screenshot in the Beam wiki here [1], the file > is titled current_CapMatExt. > > One of the proposed solutions is that after clicking the link "(click to > expand details)", we load a new page that has the corresponding table to > the click (what, where, when, how) at the top, and all the content of each > runner/function gets displayed at the bottom of the page, the file with the > proposed design is also in the Beam wiki here [1] and the file's name is > proposed_CapMatExt. This solution isn't perfect either, since we'd need to > move too much text under the table and reading isn't much easier. > > Do you have suggestions/ideas in how to condense the extended version? > > Share with us your feedback through this week, > Thanks! > G > > > [1] > https://cwiki.apache.org/confluence/display/BEAM/Website+Redesign+Files >
