Title: Re: Portal... let's talk about it
Post by: radu81 on March 26, 2015, 12:18:33 pm
Not all people are using a portal, I don't think is a good idea to integrate it. Simple Portal is a good addon, maybe one of the most downloaded for smf, and works great. Imo should remain as an addon and let developers concentrate more on forum software ;)
@emanuele if you have free time you can always try to get better the SP addon http://www.elkarte.net/community/index.php?topic=2387.0 Just kidding ;)
Title: Re: Portal... let's talk about it
Post by: Joshua Dickerson on March 26, 2015, 12:26:18 pm
What features in SP would you want to see in Elkarte? I think that's the best place to start considering it. Otherwise, I think there is a ton of work that needs to be done to make Elkarte a better product on the backend first, without worrying about adding tons of new stuff.
Title: Re: Portal... let's talk about it
Post by: IchBin on March 26, 2015, 08:52:39 pm
Seems like a lot of work to maintain both packages. I see the benefits of not having to maintain the mod separately, but really I think it's better left as a mod. Especially if you guys get to the point where mods are just dropped into a directory.
Title: Re: Portal... let's talk about it
Post by: Jorin on March 27, 2015, 12:57:08 am
Get the gallery working first. :D
Title: Re: Portal... let's talk about it
Post by: ahrasis on March 27, 2015, 03:05:05 am
SP is already an addon and I don't see why it is needed to be integrated at this stage. I agree that will be a lot more works for maintenance if both are integrated and distributed as an entity.
Title: Re: Portal... let's talk about it
Post by: emanuele on March 27, 2015, 02:08:03 pm
Basically the whole framework for blocks and the pages.
Title: Re: Portal... let's talk about it
Post by: emanuele on March 30, 2015, 06:45:02 pm
To elaborate a bit more.
Template layers are one way to do things, but thinking about this, I started considering that use "blocks" would be a much better solution[1]to display pieces of "information" all around the page (for example, this quick reply, would be a block, the same for the linktree, etc.).
Pages are a commonly asked feature (even Jorin asked for the impressum page ;)), and starting from pages, including blocks, it could be possible to build some rather complex and nice thing (for example the statistics page, could be realized as a "page" and be fully customizable through the admin panel... yeah, I know I'm partially daydreaming[2], but... who knows.)
1 Actually, what I think would be wonderful, is a layout à la java, but probably it would be "slightly" overkill. :P But I like to dream and one day I'll write one. 8)↵
2 Even though it's not really "day" at midnight :P↵
Title: Re: Portal... let's talk about it
Post by: Joshua Dickerson on March 30, 2015, 07:43:48 pm
I get "pages" but what are blocks specifically? I know what the are from experience, but can you define them?
Title: Re: Portal... let's talk about it
Post by: Bloc on March 31, 2015, 02:23:49 am
Template layers are one way to do things, but thinking about this, I started considering that use "blocks" would be a much better solution[1]to display pieces of "information" all around the page (for example, this quick reply, would be a block, the same for the linktree, etc.).
Pages are a commonly asked feature (even Jorin asked for the impressum page ;)), and starting from pages, including blocks, it could be possible to build some rather complex and nice thing (for example the statistics page, could be realized as a "page" and be fully customizable through the admin panel... yeah, I know I'm partially daydreaming[2], but... who knows.)
One thing to consider is that if you add the possibility to attach blocks to anything, it will be much harder to theme afterwards. You would lock its HTML code within the block only, not accessed by a theme(possibly). In itself its not that bad..only doing CSS, but IMHO using layers is better since it promotes themes to change its appearance.
That said..the "normal" way of adding a left/right etc. container for the blocks are outdated("panels" in TP and SP I assume). Its far better, again IMHO :) to provide a grid system, where the content is just one "cell". It allows you to quickly change the grid when dealing with mobile devices and the user have more control of the "blocks" than before. The actual grid code is locked of course - but its CSS-based so its highly customizable still.
My apologies if I misunderstood you - maybe you were thinking in similar terms?
1 Actually, what I think would be wonderful, is a layout à la java, but probably it would be "slightly" overkill. :P But I like to dream and one day I'll write one. 8)↵
2 Even though it's not really "day" at midnight :P↵
Title: Re: Portal... let's talk about it
Post by: emanuele on March 31, 2015, 03:24:09 am
Quote from: Joshua Dickerson – I get "pages" but what are blocks specifically? I know what the are from experience, but can you define them?
http://simpleportal.net/index.php?action=forum <= what is on the left column: "User info", "Who's Online", etc., each one of these is a "block", also the ADS and the welcome message are blocks.
Quote from: bh.kristiansen – One thing to consider is that if you add the possibility to attach blocks to anything, it will be much harder to theme afterwards. You would lock its HTML code within the block only, not accessed by a theme(possibly). In itself its not that bad..only doing CSS, but IMHO using layers is better since it promotes themes to change its appearance.
Not really. ;) I already played with SP and changed it so that each block is separated in its own file: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/?at=master and inside each of them the "source" part is isolated into a class, and the theming is in "normal" template_* functions: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Articles.block.php?at=master Actually, it's not yet perfect, because to override the template is not enough to load the proper file, but it's a first step (even the blocks do not use yet the classes directly, but a wrapper function that instantiate and class the appropriate method).
Quote from: bh.kristiansen – That said..the "normal" way of adding a left/right etc. container for the blocks are outdated("panels" in TP and SP I assume). Its far better, again IMHO :) to provide a grid system, where the content is just one "cell". It allows you to quickly change the grid when dealing with mobile devices and the user have more control of the "blocks" than before. The actual grid code is locked of course - but its CSS-based so its highly customizable still.
That would likely be a good idea as well, I'm playing a bit with grids (see the tentative I did with bootstrap in the past and with purecss now) but being a little terrible in theming my results are just indicative. :P
Title: Re: Portal... let's talk about it
Post by: Bloc on March 31, 2015, 04:21:57 am
Oh, a grid should really not be one already made, they add way too much unused stuff - same way I've come to appreciate the advantages in NOT using Mootools or JQuery. Because the things - IMO anyway - you need from the framework is not that harder to make in regular js. Also, if that framework is there to accomdate possible use of the many plugins - how many times do you need to that special lightbox feature lol. :P
But back to grid frameworks- there are some nice minimal ones out there..but homegrown is still better. You can make exactly what you need and be done with it. Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better. Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)
Ah, so the blocks are object-based, including its (framing) HTML output?
Title: Re: Portal... let's talk about it
Post by: emanuele on March 31, 2015, 05:29:26 am
Quote from: bh.kristiansen – Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better.
I agree on bootstrap, too big of a beast to deal with. I am looking for a very bare one, mainly because if it is already ready, "I" don't have to spend time on it. :P On the JS... yes and no. Yes, you can do it yourself, but several things are not that easy to do, and jQuery is another beast to deal with. The advantage of frameworks (usually) is that those with less experience can have something "easy to use" without having to learn it from scratch (e.g. the whole smc_* functions around in SMF/Elk code that are not really the best thought pieces of code available, and I provided my good share of niceties to them). But okay, that's for another topic. :P
I find another value in using not self-made stuff: it helps me seeing where the problems are.
Quote from: bh.kristiansen – Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)
I agree, in fact any time I start playing with a framework, the first thing I do is clean up completely the css.
The output is more "array-based", in the sense that the data to generate the block template is passed to the template as argument of the function in the form of an array. That way, the template doesn't have to deal (too much) with globals, see: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/SPAbstractBlock.class.php?at=master the HTML is outputted when the "render" method is called, the render method calls the template function passing to it the array of data built by the setup method of each block. Another thing I plan to do, is separate different "views", for example: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Recent.block.php?at=master instead of having the three situations (no data, compact, full) in a single function, I want to reach a point where there are three different functions to deal with the three of them.
Title: Re: Portal... let's talk about it
Post by: meetdilip on March 31, 2015, 05:37:32 am
May be, at this point, offering two downloads will be helpful to people realize the actual potential of ElkArte. One with just forum and forum + portal. It would be also nice to " Suggest " addons which can add interesting features through ACP.
Title: Re: Portal... let's talk about it
Post by: Bloc on March 31, 2015, 07:17:52 am
Quote from: bh.kristiansen – Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better.
I agree on bootstrap, too big of a beast to deal with. I am looking for a very bare one, mainly because if it is already ready, "I" don't have to spend time on it. :P On the JS... yes and no. Yes, you can do it yourself, but several things are not that easy to do, and jQuery is another beast to deal with. The advantage of frameworks (usually) is that those with less experience can have something "easy to use" without having to learn it from scratch (e.g. the whole smc_* functions around in SMF/Elk code that are not really the best thought pieces of code available, and I provided my good share of niceties to them). But okay, that's for another topic. :P
I find another value in using not self-made stuff: it helps me seeing where the problems are.
Quote from: bh.kristiansen – Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)
I agree, in fact any time I start playing with a framework, the first thing I do is clean up completely the css.
The output is more "array-based", in the sense that the data to generate the block template is passed to the template as argument of the function in the form of an array. That way, the template doesn't have to deal (too much) with globals, see: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/SPAbstractBlock.class.php?at=master the HTML is outputted when the "render" method is called, the render method calls the template function passing to it the array of data built by the setup method of each block. Another thing I plan to do, is separate different "views", for example: https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Recent.block.php?at=master instead of having the three situations (no data, compact, full) in a single function, I want to reach a point where there are three different functions to deal with the three of them.
I agreed, the js used in SMF is a little.. strange. It uses prototypes, and thus sort of mimicks what JQuery etc. do. I guess its a matter of preference, the one that wrote most of it, had maybe a inclination for that code style lol. I like plain js functions that do exactly what they are supposed to.
A little more on the CSS bit..I can certainly understand the need for a big stylesheet - if the templates are quite unique you want total control, every little bit put into the stylesheet. But who does that help, really? Not the themer, they are too afraid to change anything beyond what they "know". Not the user..they don't look at it anyway(but they do feel it when having to dl the 100k+ file on their mobiles ;) ) ..so I guess..the dev? So its really more a question of having a good base: the templates themselves. If theya re simple enough, the basic CSS can be simple, and custom themes would be the ones to be complex. Not the other way around.
Quote from: meetdilip – May be, at this point, offering two downloads will be helpful to people realize the actual potential of ElkArte. One with just forum and forum + portal. It would be also nice to " Suggest " addons which can add interesting features on ACP.
It sounds nice..but as always: someone got to code it :)
Title: Re: Portal... let's talk about it
Post by: meetdilip on March 31, 2015, 07:48:37 am
I guess there is already a news feeder in ACP. Simply create a blog with interesting / recommended features and pull the feed from it.
Title: Re: Portal... let's talk about it
Post by: emanuele on March 31, 2015, 08:48:33 am
Quote from: bh.kristiansen – A little more on the CSS bit..I can certainly understand the need for a big stylesheet - if the templates are quite unique you want total control, every little bit put into the stylesheet. But who does that help, really? Not the themer, they are too afraid to change anything beyond what they "know". Not the user..they don't look at it anyway(but they do feel it when having to dl the 100k+ file on their mobiles ;) ) ..so I guess..the dev? So its really more a question of having a good base: the templates themselves. If theya re simple enough, the basic CSS can be simple, and custom themes would be the ones to be complex. Not the other way around.
I perfectly agree (if I understood you correctly), you see that most of my proof of concept (I feel ashamed call them themes lol) are very, very, very minimalistic, without much styling. From day 1 I say that for the default theme the best way would be what wordpress does: a basic, almost empty, well structured, boilerplate, and nothing else. Unfortunately, at the moment, even a simple empty theme requires quite a bit of code, just because of the many slightly different templates we have to deal with, so the very first thing to do is clean them up. Not a quick and easy task, it's in the process, it will take a while.
That doesn't really mean we have to use the default theme here, of course. :P
Title: Re: Portal... let's talk about it
Post by: Eliana Tamerin on April 03, 2015, 06:01:34 pm
In the past (especially after SMF went open source), the SimplePortal Team has considered offering a bundled SMF+SP installation for its users. We discovered a couple problems with this:
1. Users don't seem to understand that the bundled portal is a mod that can be added after the fact, so the users who unwittingly choose the base SMF version or otherwise don't opt for the bundle feel as though they have been left out. This can lead to forum destruction (removed forum to install bundled version), complaints, and general FUD.
2. Intrinsically linking SMF and SP also comes with the consequence of linking their bugs. There have been a few instances where a problem reported at SP.net is actually an SMF bug or problem. We can help a little bit with these support issues, but at some point they have to be turned over to SMF. With such a small team at SP, it's impossible to truly support any SMF bugs, and by linking the two we are granting the perception that we are responsible for both software problems. This may not hold as true for Elkarte, since it would be the opposite, but it would additionally require Elkarte devs/support members to be familiar with SP as well as Elk, or to simply overwork @Spuds.
I would seriously recommend that Elkarte not offer bundled installs. Either the portal is fully integrated or the portal is featured among 'popular mods' or such things in the Elk admin CP.
Title: Re: Portal... let's talk about it
Post by: radu81 on April 03, 2015, 08:08:36 pm
Quote from: Joshua Dickerson – What features in SP would you want to see in Elkarte? I think that's the best place to start considering it.
one is this http://www.elkarte.net/community/index.php?topic=2387.0
And also the pages, a category for pages would be great with the possibility to list pages from categories. But maybe this is something that usually cms does