My last post in this critically important thread was way back in May 2017. It’s now almost March 2019. While I know for certain there are many juicy features on Norms TO DO list, I once again would like to appeal for Responsive Tables. This is the single most important feature for me, and it seems like for many of you too. Second to responsive tables is a site wide search feature, preferably one that ties in with Google Custom search, which is what I use now in my Freeway sites.
Hi @JDW ,
I have to smile a bit and give you a litle wink as you are not giving up your wish for tables.
Also I would love this feature just for small price/period tables (althogh are cards beautiful they would use a lot more space).
Implementation via html widget is possible, but adding/changing data via code makes it more or less not worh to use by now).
I am pretty sure we will see this future and it might be not so far away as bootsrap 4 includes this feature.
But I also understand @Norm having his focus currently on more important features as we are the only ones always remembering how useful it is to us.
I’m curious which tools similar to Blocs do this out of the box. This can fuel some ideas I think, and would be helpful. What I’ve seen from 3rd party tools would not be appropriate I think for Blocs core, and certainly not possible with the current api.
Thank you. I know some have shared a need for tables but I personally I don’t see how it would fit using core blocs.
I to would like to know of any that really support tables. It just seems that with mobile device usage continual on the rise tables just seems old school to me.
I’m sure someone with programming skill like yourself would be able to find a solution, maybe just not in Blocs.
In a previous post, waaaaaaaaaaaaay back in 2017 in this thread, I posted a video on how SoftPress Freeway does it. I know this very well because I still use Freeway to this day and have been a continuous user since 1999, in fact.
I disagree that we need “more patience.” We need “more people” asking for this same feature. If every Blocs user asked for it, no doubt it would pretty quickly move up on the priority list.
And just because another similar web design tool (similar to Blocs) doesn’t have a responsive table feature doesn’t mean it is impossible to implement. Indeed, it could be a very UNIQUE SELLING POINT of Blocs!
Seriously, the absence of a table Bric and a Search Bric are pretty much the only two reasons I still use Freeway. I cannot rebuild my existing sites in Blocs without those features. And since many pages have tabular data in tables that are very large, doing it all in code in Blocs isn’t realistic.
It doesn’t need to be anything fancy. Heck, the table tool in Freeway isn’t fancy. I might even be willing to say “forget it even being responsive and just give me a WYSIWYG table tool in Blocs.” It’s best if its responsive, but if that will take another 10 years to implement, then throw out the responsive and give me what you can now, in Blocs, in a nice WYSIWYG manner, with no code hacks required.
Even if some argue that “a good number of Blocs users do NOT need a table tool,” it’s really not possible to say that in any factual way. It’s not like we’ve taken a poll. And I assure you that once it’s implemented, all Blocs users will sit wide-eyed in awe, eager to give a try.
2.5 k visits on this topic - not counted further table topics.
Guess this speaks for itself
I bet the first 3rd party developer offering a functional solution will earn something
@casey1823, I don’t have a need for tables, but Norm mentioned that he would like it to be a custom bric once the api is completed rather than in core. I very much would like to see the API completed so I usually perk up at its’ mention.
My official opinion is that using a dedicated table maker is actually much faster and feature rich than making a bunch of tables using a Blocs interface IMHO.
Take this tools for instance:
You can save, import, export etc. It’s got a ton of output languages and can really be implemented faster that a Blocs UI will at this point. Anyone serious about tabular should love this as a concept (there are many to choose from). It’s the best way to reduce labor, make tabular data portable (move it to other table tools you find). In fact people could be using this tool easily right now with tables they’ve made from long ago and update them in style and content.
I wonder if there’s any convincing someone who just wants it in Blocs that there’s actually a better way. I would do this 100 out of 100 times if my tabular data was coming from a source that I could export in .json or HTML or Markdown etc. Like say Google Sheets, Excel etc.
Hopefully the crowd actually wants tabular data solution and not just tabular data through Blocs interface at any cost. The latter should have to wait until the Blocs developer is good and ready.
Although there seems to be financial gain in building one, I wouldn’t release it until the API is out of beta like so many of the custom brics I have waiting and planned.
I know the “waiting game” all too well. Again, I’ve used Freeway since version 2.0 in 1999, and still use version 7 Pro to this day, albeit while dabbling in Blocs since 2017. The thing with Freeway is that important features took literally decades to implement and some key features like easier design of responsive sites are still being worked on. (Yes, SoftPress resurrected from the dead and is working on a 64-bit rewrite of Freeway.) Ask any Freeway user about “the waiting game” and you’ll get many stories of sorrow. It’s now that these folks hate Freeway. Indeed, many love it. But they know that some features may never see the light of day in light of the fact they were requested many years ago (some 15 years ago) and still haven’t made it into the lime light.
Nobody has time. We have to make time. Nobody really cares enough about a given thing until they make the concerted effort to push themselves beyond their comfort zone. Feature creep and distractions are common excuses for putting some features on the back burner. But as I’ve always told SoftPress, at some point, features that were requested years ago, and which would serve a good purpose for users in general, should be given higher priority at some point. For example…
Let’s say you have a system whereby a feature is given a 1 or 2 or 3 in terms of priority, where 1 is the highest priority. Let’s say a feature request is given a 3, regardless of reason. Two years go by. Should it still be a 3?
My contention is that a feature request that has a lot of usefulness potential should automatically be bumped up in priority over time. A couple years go by, it should automatically get the rank of 2, then another year or so it should get a 1. And at that point, it should get implemented quickly, with no more excuses for delays, regardless of “how important” those millions of other features are.
I advised SoftPress in this manner for decades. It largely fell on deaf ears. I am pleased though that some of my feature requests did make it into Freeway. Without them, Freeway would not have been in my software arsenal for so long. It is therefore my desire to see Blocs developed in a way that USEFUL features can be added over a reasonable amount of time. Now scroll up and view the data on this thread. It’s dated December 2016. Today is Feb. 2019. That’s just over two years. To me, that means a 3 should at least get bumped up to a 2 in priority, regardless of arguments about other “more important” features. And this is a truth that speaks no evil toward Blocs or its outstanding developer or its great community of good people. It is possible to be persistently strong with constructive criticism because you love a thing and want it to be better. That’s what I’ve done for Freeway. That’s what I’m doing for Blocs.
Web design technologies continue to progress every year and it will never stop. Just because something was asked for 2 years ago doesn’t mean it works it way up the list. This is because every year new things come into play and quickly become essential requirements, in fact the opposite could be said for some requests, they actually get pushed further down, they become even less of a requirement.
So to put it into context, here are two options that would take a similar amount of time to develop.
Option 1: Add support to visual manage tables within Blocs.
Option 2: Add support for CSS grid (modern CSS layout system).
In my option one of these options is heading in a backwards direction and the other forwards. My goal is to take Blocs forward.
It seems that CSS Grid consists of rows and columns (i.e., tables for tabular data), and that would appear to be the modern, forward-looking Option you wish to pursue. So I don’t see any problem here, so long as we can enter data in Blocs via some WYSIWYG means rather than create the table elsewhere and then be forced to dump code into Blocs to make it work.
I would have to totally agree with @Norm here. I understand that having both visual tables and css grid will be the best, but if we have to prioritize one, I don’t think visual table editor is critical.
Plus, you can already build pretty much usable tables inside Blocs using the column row bric. Below is the little example I was able to put in place in 15 mins.
Of course, it is a bit of work at first, but after you figure out the first couple of table rows (for all breakpoints), then just duplicate and replace the text. Not that difficult. And for mobile breakpoint, I just created a separate smartphone version.
In summary, some situations can require use of tables, but I think that current functionality of Blocs is enough for these cases.
Nice, @Eldar another fine example of just thinking about how Blocs can achive something like JDW example. I went in an inspected the element and it’s really just a row with five columns, the last column having a three column row nestled inside. Nothing that Blocs can’t handle. I know it takes a little work getting it to look good on all breakpoints but it’s very doable.
Thanks for showing that this type of reponsive layout can resemble an old school table using just Blocs.
Blocs 3 is one of the best web building solutions on the market!
I’m always astounded what @Eldar is capable of doing. Both of these example are really good, but they are not sort-able. I don’t think Blocs can do that without using code.
Eldar, I am impressed. Would you mind putting your document into this thread as an attachment so we could examine your handiwork in more detail? I am eager to see precisely how you accomplished that amazing feat!
Thank you, Eldar. I see what you’ve done now. It’s not similar to Freeway where you have a dedicated table tool that you tell “7 columns and 8 rows” and then start filling it out like Excel. Rather, you have to think out the design, manually add all your Blocs-defined Columns and Rows, and then add paragraphs, and then add your content, and then build yet another table that will conform to a smaller screen breakpoint.
I wonder if it would be possible for Norm to add a new Bloc called Table that would ask us for the number of rows and columns and then build a basic layout based on that user input, with all the necessary paragraphs inserted for us, so that manual labor is avoided. Then of course we would need to resize the width and height, and add color, to our liking, as well as style the text. And I suppose we would still need to manually add at least one more table for the smaller screen breakpoint, then style that.
So what I am saying is, I wonder if there is some way Blocs could assist us in creating what you created, just a tad bit faster and easier. Why is faster and easier important? Well, for people with many tables in a single site, faster and easier can save a lot of time.
Yes, that’s pretty much it. As for mobile breakpoint, it is possible to create a small version of table without create a separate smartphone version, but it obviously depends on what kind of design you want to have. For the table on your site, I thought it will suit it better.
I understand hat it is a bit more time consuming to create tables like this, but I think it gives much more freedom to build almost any type of design. I doubt it will be better to use pre-built table bric if it offers just number of rows and columns. Like I said, the method I have used heavily relies on duplicating and replacing the text. The only difficult part is the first couple of rows.
I think it could easily be a 3rd party bric. If I have time to learn this development part of using Blocs, I might create something like this myself. Maybe some of our community developers who feel the need for a bric like this will do that.
So, yes, at the end of the day. The amount of work will be not that different to what we have right now. It’s very easy to customize the table I have created just by using a few custom classes, which we can just copy and paste to other columns and rows.
Yes, if Blocs could assist us to make the process a bit faster, it would definitely be good for people who use tables on many pages. At the same time, 1)create a couple of rows 2) duplicate rows to create a table 3)save this row in a custom bloc 4)reuse it on any page. All you will have to do is to input the data manually, which you will have to do anyway.
as you are not giving up your wish for tables.
