SMF Development > Next SMF Discussion
My SMF 3.0 Dream
Antechinus:
1 Yup.
2 Yup.
3 We have already decided to support jQuery as using a pre-existing library makes a lot of sense, and jQ is the de facto standard these days.
4 Yup.
@Oldies: I realise menu edits are easy for us. "Oh, all you have to do is delve into the depths of Sources and edit a complex PHP array. Make sure to get your syntax right or you'll crash your whole site. Have a nice day."
It's not the way to go if you really want to support a broad user base. Most people are not coders and do not want to be coders. They don't feel they have the time to learn coding on top of everything else in their lives. If you want to enable them to run their own forum, you should be making it easy for them.
5 Makes a certain amount of sense.
6 Ditto. Never been a fan of lots of profile fields anyway. Just a few basic ones would do me.
7 Bit of a toss up on whether to keep it as core or not. Not sure at the moment.
8 I agree that permissions need an overhaul.
9 Definitely.
10 I'm all for reducing http requests, and I often merge custom js files and css files when doing custom work anyway. The one exception would be jQuery itself, as calling that from Google CDN makes the most sense since a lot of people will already have that cached. To my mind, the best way of handling jQ would be to call from Google by default, with a fallback to the forum's own copy if the Google file happens to be unavailable for some reason.
11 Never use notifications anyway, so am personally ambivalent about the whole thing.
12 Ditto. I'd probably want an off switch for that one.
13 Definitely. IE6 is only going to be minimally supported. Same for IE7. IOW, we'll probably do a quick check to make sure critical functionality is still operational, but we wont care what it looks like.
14 Yup, or it should come with a separate mobile version (which is probably better, really).
15 Yup.
16 Would keep the post page, but have an option of bare bones or advanced quick reply for those who want it.
17 Yup.
18 Not in favour of pretty url's by default.
19 The plan is to keep it without a sidebar. Anyone who wants extra blocks can install a portal.
20 Not a bad idea.
21 Will be using mainly png, but possibly SVG for some things. PNG's are very light if used sensibly (often lighter than gif).
22 Speaking for myself, I would happily scrap karma and not replace it with anything.
23 I'll leave that one to the back end boffins. Me do templates n css. :P
24 So you want fewer profile fields but more stuff in profile? Ok. How does that work? :D
25. Sounds like a good idea.
26 Would be fine with that.
27 Same as notifications. Couldn't care less, so will see what others think.
28 Not sure I'd use it myself, and it does complicate an already complex system, but I can see the sense in the idea.
29 Probably better as a mod. Certainly not something I'd prioritise for core.
30 Already been over that. :)
31 Yes. Menu manager and file uploads are obvious places for this too.
32 I'd like it myself, and will probably add custom code for it so staff can use such a function, but not a good idea for general use/inclusion in core.
33 Makes sense.
34 Ditto.
Help Forums Evolve!
--- Quote ---1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.
Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.
If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.
It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.
--- End quote ---
Interesting thoughts, but offhand I'm inclined to think that this is where portals start to make sense as they allow similar things already. Not entirely sure it makes sense for a forum core module.
--- Quote ---2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!
--- End quote ---
Not sure how well that would actually work.
--- Quote ---3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.
--- End quote ---
Meh, with the obvious exception of OpenID (even though hardly anyone uses it AFAICT).
Bloc:
All of them would be nice to add for SMF 3.0. though I highly doubt most of them will ever make it.
(curiously its a similar wishlist of what I like ViennaBBS to be - except JQuery, Mootools is my choice. But def. the options to show topics as "types" is a "must")
kimba:
Regarding the option to send attachments in PM, while I agree with what people have said, I'd like to think it is nice to be able to send files to each other. The reason I say this is because people might not want their email address to be public to anyone.
One example this option could prove beneficial would be in a forum such as this one where members might want to send coding scripts to mod/theme creators for review or editing.
However, I do agree that it can cause some legality issue regarding its contents ...
Kindred:
send scripts using the CODE tag....
Even if attachments in PM was ever included, it would definitely be turned OFF on a forum like this one.
Oldiesmann:
I personally do not see a need for PM attachments. There are plenty of sites available for sharing whatever it is you'd need to share via PM without having to allow attachments (Pastebin for code; Image Shack, Photobucket and many other sites for images; Pipe Bytes, Dropbox, etc. for files).
The other problem with PM attachments is that we'd have to include a way for admins to manage them just like regular attachments, only with a bit more functionality since the files would be shared between specific members instead of posted in the forum where the admin can see them. We have always been against allowing admins to view their members PMs, and it would be difficult to properly handle PM attachments without allowing admins to view the PMs.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version