Hey everyone!
I've put quite a bit of thought into what I think SMF 2.1 should have, should not have, and what should be modified, so I thought I might as well share these thoughts with the public.
Database Support:
In my opinion, SMF should just support MySQL, or have the option to select their database type on the installation.
Browser Support:
All old browser support should be dropped, such as IE6. There are quite a few limitations supporting old browsers cause, and there has to be some point where developers can develop Web 2.0 code without worrying about old browser compatibility and having to code a lot of extra lines to keep it compatible with ancient browsers.
CSS3 & jQuery Implementation:
jQuery is most definitely in the future of the web, it is highly extensible and at the same time lightweight. If for no other reason, it should be included on a boolean variable for mod authors to enable if their mod uses it.
In my opinion, the default theme should also contain some nice attributes that CSS3 has to offer.
Spellcheck:
Most modern browsers contain some form of spell-check built in, or an addon for it. SMF's also requires a third party script to run. So in my opinion, it's not even practical.
Although I do believe it could be updated, and provided as an official addon/modification.
Calendar:
I believe the Calendar should not be a core-feature. I think it should be removed from the SMF Core, and completely re-written to have an AJAX/jQuery fancy interface, provided as an official addon/modification.
$smcFunc & PDO:
$smcFunc should be re-written as a PHP Object for easier usage, and a much shorter line-count to accomplish a much better result. Plus some more automation such as auto-data type with the ability to over-ride? For instance, with $smcFunc in 2.0, you have to declare each columns data type, such as 'field' => 'int', and so forth, but this can be figured out with PHP very easily, with no need to declare each column.
Along with the PHP Object, PDO should be implemented for data sanitation.
File Based - Database Modifying - Menu:
There were huge benefits with the move of the menu from template files in 1.1, to Source side in 2.0, however this still could be much more customizable for forum admins who do not know any coding, and even for those who do, much more simple and quick.
The solution is a file-based, and database driven modifying for the menu, with a very customizable and easy to use interface in the admin panel. (Menu Editor Lite + some features of full)
BBC Editor??
It wouldn't be bad to consider the same idea of "Menu Editor" for Bulletin board code, such as the ability to remove bbc items, or add custom ones, permission to use one, and so forth, through an easy interface, outputted to a file so there wouldn't be any extra queries on a regular page load.
Bloated Profile Fields:
I believe bloated profile fields as "MSN" - "ICQ" - "AIM" - "YIM" should be removed. With the addition of Custom Profile Fields in SMF 2.0, why provide some fields, but by no means them all? What about Skype, Google Talk, Facebook? I think it's much better to remove all un-necessary fields but allow them to be added easily through Custom Profile Fields. You could even have "Custom Profile Field Templates".
Customizable Memberlist:
The memberlist should be configurable through the admin panel, with different two different listing styles. Block / List.
Buddy List:
The buddy list is very limiting, and practically useless. This should be moved to an actual database table, and the features expanded.
Profiles:
The profile sections of SMF are lacking, and very behind today's technology and social aspects. Inline editing, more social such as visitor messages / comments / notifications / etc.
Captcha:
Recaptcha to replace SMF's default captcha?
PM Attachments:
Personal Messages should definitely have the ability to include attachments.
Quick Reply vs. Posting Page:
The possibility of completely removing the actual "post" page and making something similar to Quick Reply be the main form of posting, with BBC editor obviously, and attachments. (Attachments powered by AJAX?)
News / Newsletter:
Provide a more intuitive Newsletter system, with a more advanced news system being an official addon/modification.
Smartphones:
Who doesn't have a smartphone today? Provide jQuery Mobile for smartphones. "Posted from iPhone" or "Posted from Android" (very simple to addon, but a neat idea imo)
Email Template Editor:
Provide a simple but customizable interface to modify email templates? Probably better kept out of core, and added as an official modification.
External Links / Blacklist:
The ability to "blacklist" an address, when the link is clicked, warn the user that the link is blacklisted, ability to proceed or stop. Let users know that they are clicking a link that is external. Enable or disable...possibly a modification rather than core.
Users Online Today:
This should definitely be a core feature by now.
.gif's:
Remove all of the old .gif's that are old fashioned looking, and replace with a nice new icon pack.
I have more thoughts, but I think this enough for one post.
Definitely feel free to comment or question any of my ideas.
The Calendar may not be everyones cup of tea ( or coffee)
BUT on MKAware our Calendar is full of local events although I would prefer to see more member birthdays too.
1) That's why it would be a new fully re-written Calendar, with much more functionality, and with jQuery so it'd be much more fancy and up to date. (most useful as a modification imo)
2) You can still show birthdays without the calendar...not that hard to make possible.
QuoteIn my opinion, SMF should just support MySQL, or have the option to select their database type on the installation.
+1... possibly make the alternative database files as official plugins.
QuoteAll old browser support should be dropped, such as IE6
+1
QuotejQuery is most definitely in the future of the web, it is highly extensible and at the same time lightweight. If for no other reason, it should be included on a boolean variable for mod authors to enable if their mod uses it.
I wouldn't agree on the lightweight part, unless you had 1.3 in mind.
If jQuery does end up being included, why not also rewrite most if not all the existing javascript to use jquery and the $ function?
Quote
In my opinion, the default theme should also contain some nice attributes that CSS3 has to offer.
YES +100 DEFINITELY!! Just think of everything that could be replaced: rooundeed corners, gradients, zebra-striping.
QuoteI believe the Calendar should not be a core-feature. I think it should be removed from the SMF Core, and completely re-written to have an AJAX/jQuery fancy interface, provided as an official addon/modification
.-1. It can and should be improved. Maybe then it'll get what it deserves...
QuoteI believe bloated profile fields as "MSN" - "ICQ" - "AIM" - "YIM" should be removed. With the addition of Custom Profile Fields in SMF 2.0, why provide some fields, but by no means them all? What about Skype, Google Talk, Facebook? I think it's much better to remove all un-necessary fields but allow them to be added easily through Custom Profile Fields. You could even have "Custom Profile Field Templates".
+10
QuoteThe memberlist should be configurable through the admin panel, with different two different listing styles. Block / List
+1... also custom profile fields should have the option to be shown on the memberlist. See Sinan's mod.
QuoteThe buddy list is very limiting, and practically useless. This should be moved to an actual database table, and the features expanded.
+1... see the enhancement to buddies in the ultimate profile mod.
QuoteThe profile sections of SMF are lacking, and very behind today's technology and social aspects. Inline editing, more social such as visitor messages / comments / notifications / etc.
+10... see above
mod.
QuoteRecaptcha to replace SMF's default captcha?
I feel this one to be shot down if only because it relies on a third party service if I recall correctly. Why not include Bad Behavior and decrease the default captcha to easy and remove complicated levels starting from high? Maybe then less people would complain about the "horrible captcha". Signed, a user who has a hard time solving these puzzles.
QuotePersonal Messages should definitely have the ability to include attachments.
+10
QuoteIf jQuery does end up being included, why not also rewrite most if not all the existing javascript to use jquery and the $ function?
+1 exactly...
QuoteYES +100 DEFINITELY!! Just think of everything that could be replaced: rooundeed corners, gradients, zebra-striping.
Amen.
Oh, also get rid of the old fashion .gif's and replace with some nice new icons?
Quote.-1. It can and should be improved. Maybe then it'll get what it deserves...
Sure, either way though, it needs a full re-write with jQuery, new features. Whether or not it's a modification or core doesn't really matter, but it definitely needs an update.
QuoteI feel this one to be shot down if only because it relies on a third party service if I recall correctly. Why not include Bad Behavior and decrease the default captcha to easy and remove complicated levels starting from high? Maybe then less people would complain about the "horrible captcha". Signed, a user who has a hard time solving these puzzles.
Well, the spellcheck requires a third party...maybe just officially support this addon.
I could quote every thought, but that's too much work. Let's keep it on a +100 for your whole post :) I couldn't agree more with everything
Quote from: Dr. Deejay on September 21, 2011, 02:31:37 AM
I could quote every thought, but that's too much work.
Too much work then? Hm, doing multiple quotes like that is very time consuming. For me, the work lies in ttyping actual stuff :D
Time is money ;D
eheheh
Why thank you :)
Quote from: Dr. Deejay on September 21, 2011, 02:31:37 AM
I could quote every thought, but that's too much work. Let's keep it on a +100 for your whole post :) I couldn't agree more with everything
I'd reply on every point, I pretty much agree with what live627 has said above. :)
Quote from: Labradoodle-360 on September 20, 2011, 08:39:47 PM
Well, the spellcheck requires a third party...maybe just officially support this addon.
Actually, the spellcheck just requires PHP to be compiled with aspell/pspell support. That's not a 3rd party tool in the same sense as ReCaptcha. ;)
ReCaptcha is owned by Google. Doesn't Google pretty much own everything on the web? :P I'm sure they have to have some sort of API.
Recaptcha is useless now. It was broken by the spambots several months ago.
Ditto +100 on the entire initial post.
I actually think that the default SMF captcha is stronger than ReCaptcha. When I used a site with ReCaptcha, I had bots everywhere. When I set the default SMF captcha to high/extreme, I have no problems with bots at all. loving the rest of the post! +99 :P
According to what Kindred said, that would be accurate. But I still think SMF's Captcha could be at least re-styled...
I don't even use it. Switched it off completely. Haven't had any bigger problems since doing that either. It made absolutely no difference. IMHO, captcha is obsolete and not worth bothering with. All it does is annoy legitimate new members.
That's probably true, Facebook doesn't have Captcha...I think Email Activation is smart though.
Quote from: Antechinus on September 26, 2011, 05:38:03 PM
All it does is annoy legitimate new members.
Even if it's set to simple/very simple?
Quote from: Labradoodle-360 on September 26, 2011, 05:41:09 PM
I think Email Activation is smart though.
It does filter some robots... however, spammers can and do get past that. That is where Bad Behavior works so well; because some spammers use unsafe agents , they get blocked.
Yeah live, that's true.
Quote from: live627 on September 26, 2011, 06:28:42 PM
Quote from: Antechinus on September 26, 2011, 05:38:03 PM
All it does is annoy legitimate new members.
Even if it's set to simple/very simple?
ROFL. If you use that setting it has absolutely no security benefit anyway. However, it is still a minor irritation for genuine users.
If it has absolutely no security benefit, why is it still on the base of the software? :P
Legacy code, in my humble opinion. It was useful until fairly recently, and some people might be worried if it wasn't there.
Quote from: Antechinus on September 27, 2011, 05:51:14 PM
ROFL. If you use that setting it has absolutely no security benefit anyway. However, it is still a minor irritation for genuine users.
/me thinks of ArantorCaptcha...
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
In my opinion, SMF should just support MySQL, or have the option to select their database type on the installation.
I have a concern over dropping everything except MySQL support. Oracle is pushing MySQL towards an "open core" model where only the very core of MySQL is open source. Everything else is closed-source and possibly heavily licensed and expensive if it's not for personal use (e.g. hosting companies would need to pay).
I'm not against using commercial software. Rather, I'm concerned about locking up a product which has had significant effort expended to support multiple backends when the one "chosen" backend is being produced by a company that has a direct interest in monetizing that backend and making sure it never eats into the company's main product.
Personally, I think more effort should be made to either extend the multi-database support into a proper db abstraction layer, or even an ORM. That, or finding a lightweight, license-compatible multi-database ORM that can be used.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
All old browser support should be dropped, such as IE6. There are quite a few limitations supporting old browsers cause, and there has to be some point where developers can develop Web 2.0 code without worrying about old browser compatibility and having to code a lot of extra lines to keep it compatible with ancient browsers.
Agreed, especially given the declining relevance of that version on public sites. However, it would be useful to somehow get statistics on the browser makeup for SMF users to make sure it's fully a wise choice.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
jQuery is most definitely in the future of the web, it is highly extensible and at the same time lightweight. If for no other reason, it should be included on a boolean variable for mod authors to enable if their mod uses it.
In my opinion, the default theme should also contain some nice attributes that CSS3 has to offer.
Supported as long as an eye is given to proper degradation. No breaking functionality to where stuff doesn't run simply because JS isn't being processed by the browser.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Most modern browsers contain some form of spell-check built in, or an addon for it. SMF's also requires a third party script to run. So in my opinion, it's not even practical.
Although I do believe it could be updated, and provided as an official addon/modification.
SMF uses PHP's built-in aspell support via the pspell module, so it's not third-party. However, pspell has been deprecated in favor of enchant. PHP 5.3 doesn't support pspell at all. Effort should be made to either move to enchant or drop server-side spell checking.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
I believe the Calendar should not be a core-feature. I think it should be removed from the SMF Core, and completely re-written to have an AJAX/jQuery fancy interface, provided as an official addon/modification.
Agreed. The calendar has long been neglected and it's tangental to the purpose of a discussion forum. An officially supported modification would be the best way to go along with enhancing the calendar to make it more useful. Please do note my comments above about not breaking if JS isn't being run.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Plus some more automation such as auto-data type with the ability to over-ride? For instance, with $smcFunc in 2.0, you have to declare each columns data type, such as 'field' => 'int', and so forth, but this can be figured out with PHP very easily, with no need to declare each column.
I think that was done for data protection so that if a variable gets data that doesn't match the assigned type, it wouldn't be used. Can this be done automatically? My understanding is that it couldn't be easily done.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
I believe bloated profile fields as "MSN" - "ICQ" - "AIM" - "YIM" should be removed. With the addition of Custom Profile Fields in SMF 2.0, why provide some fields, but by no means them all? What about Skype, Google Talk, Facebook? I think it's much better to remove all un-necessary fields but allow them to be added easily through Custom Profile Fields. You could even have "Custom Profile Field Templates".
Agreed. At least two of those messanger services are barely used today. Moving to custom profile fields would be a great way to avoid having to pick services, especially when ones like QQ are popular regionally (and useful for forums serving people in that region) but not globally.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
The buddy list is very limiting, and practically useless. This should be moved to an actual database table, and the features expanded.
What kind of features are you thinking?
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
The profile sections of SMF are lacking, and very behind today's technology and social aspects. Inline editing, more social such as visitor messages / comments / notifications / etc.
I guess. I never use those features on other boards, but I am sure some people spend 60%+ of their time in those areas.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Recaptcha to replace SMF's default captcha?
Third-party external service that requires WAN connection. Probably won't happen. It's also widely targeted by various spambots, so just changing around the custom functionality would probably be more effective. (I say this, being the maintainer of the reCAPTCHA modification.)
Note that several human-backed services such as CAP****bot (censored as I'm not giving them free publicity) are widely used by spamming tools. These services use real humans to solve image puzzles, nullifying the purpose of having them on your site in the first place.
Oh, if you try to look up the solving service I mentioned, do be careful. It's run out of Eastern Europe by the same type of people that do scareware and drive-by infections. The site has the potential to be dangerous.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Personal Messages should definitely have the ability to include attachments.
There was some concern over this when it was suggested before. Not only do you now have a potential problem of attachments taking up space on your site, you have some potential legal issues as well. For instance, you may get two people trading child pornography via PM (rare, but it sadly does happen). Now your website is hosting illegal material. You also may get some adult sending a child nude photos (sadly, probably less rare than the first scenario), creating more issues. Then you also have the problems of someone sending malicious files and trying to get users to run these files - kinda like what happens in e-mail now.
Without a way to monitor these files, you're opening yourself up to some big problems with this feature. Since these are ostensibly personal, monitoring these things isn't really a solution.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
The possibility of completely removing the actual "post" page and making something similar to Quick Reply be the main form of posting, with BBC editor obviously, and attachments. (Attachments powered by AJAX?)
There should always be a post page if only for those users running in constrained environments (mobile, for example) where heavy JS would not work well. Likewise, the ability to hide all the editor "chrome" is useful for reducing data transfer size and just removing clutter when the user knows how to type bbc.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Provide a more intuitive Newsletter system, with a more advanced news system being an official addon/modification.
Agreed, kinda. It would be nice to have a newsletter archive without needing to manually make one. Also, some thought should be given into what to do with the news system.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Who doesn't have a smartphone today? Provide jQuery Mobile for smartphones. "Posted from iPhone" or "Posted from Android" (very simple to addon, but a neat idea imo)
Just using JS to add a line of text?
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Provide a simple but customizable interface to modify email templates? Probably better kept out of core, and added as an official modification.
Agreed.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
The ability to "blacklist" an address, when the link is clicked, warn the user that the link is blacklisted, ability to proceed or stop. Let users know that they are clicking a link that is external. Enable or disable...possibly a modification rather than core.
I see a lot of ways of going around this. There are tons of URL shorteners that can obfuscate an address. Having an external modification that can treat external links specially might be interesting.
QuoteI have a concern over dropping everything except MySQL support. Oracle is pushing MySQL towards an "open core" model where only the very core of MySQL is open source. Everything else is closed-source and possibly heavily licensed and expensive if it's not for personal use (e.g. hosting companies would need to pay).
I'm not against using commercial software. Rather, I'm concerned about locking up a product which has had significant effort expended to support multiple backends when the one "chosen" backend is being produced by a company that has a direct interest in monetizing that backend and making sure it never eats into the company's main product.
Personally, I think more effort should be made to either extend the multi-database support into a proper db abstraction layer, or even an ORM. That, or finding a lightweight, license-compatible multi-database ORM that can be used.
At least make the install script smart enough to delete the other database system files.
QuoteSupported as long as an eye is given to proper degradation. No breaking functionality to where stuff doesn't run simply because JS isn't being processed by the browser.
There has to be some point when the people without JS just need to turn it on. The majority of people do have JS on, the people that don't will need to eventually or the web won't be able to advance. Same thing with old browsers really.
I do agree some noscript stuff should be implemented, but not to the point of restricting the functionality of jQuery and what it can do.
QuoteI think that was done for data protection so that if a variable gets data that doesn't match the assigned type, it wouldn't be used. Can this be done automatically? My understanding is that it couldn't be easily done.
You can use functions such as is_int(); or is_string(); to determine whether it's an int or a string, and there are others for different types of course, so yes, it's easily possible. Just some validation and error throwing if it's not inside of one of those.
QuoteWhat kind of features are you thinking?
Just some more friend settings, the ability to add a friend with requests and so forth.
QuoteI guess. I never use those features on other boards, but I am sure some people spend 60%+ of their time in those areas.
Whether everyone would use it or not, a lot of people would, SMF is behind in my opinion socially.
Despite the whole personal message issue, I still think it's not a huge deal if you have a disclaimer. Especially with the report to admin PM function.
- Not having a post page wouldn't decrease the performance?
- Posted from a Smartphone could be a line of JS...or it could be a line of PHP that would determine the OS. (Which is already implemented in SMF) [I actually think I might write this mod up shortly]
Although there are a lot of link shorteners, Facebook still has a blacklist check afaik.
I actually dislike the idea of the "posted from my phone" line. I remove that crap that the phone auto-adds by default as soon as I get the phone. I don't want people to know if I am posting from a phone or a computer unless it is specifically relevant, in which case I'll mention it.
I suppose it's all in taste.
/me decides to add a user toggle for "Posted from my iPhone" - "Posted from my Android".
i would rather not even have it as a option and just not show it. i dont care if they are posting from a cell phone yet what phone it is.
Then don't install the mod I write, and forget it from my thoughts on 2.1 features ;) Thanks for being positive and encouraging.
I actually really like it, and I'm sure there are others who would find it useful.
then it should be an option from the admin panel AND an option from the users side as well if it were to be a default feature.
That's exactly how Look and Layout settings work...
not all of them can be locked by the admin so they can not be changed by the user at all.
Some of the other ideas are good, but I honestly can't see why having extra text declaring what phone something was posted from would be either useful or desirable. Personally, I find it slightly annoying when I see it attached to a series of posts. It's just useless clutter IMHO.
Lab: you posted your ideas. Other people have their own ideas. There's no need to get snarky if someone else expresses their views. Giving an honest opinion should be seen as being positive.
Just to clarify quickly a small thing here,
SMF will continue and improve support for other database systems. While $smcFunc is not really a too nicely designed database API, that doesn't mean that is multiple databases feature's fault. :). We're looking into improving it. I played with a possible alternative, will see how it goes. Personally, I cannot even imagine a package with the intended userbase, (relative) generality of a forum system, and its upcoming years (yes, also considering the conditions of questions about MySQL's faith itself, though afaik MariaDB is an option), hard-coding a single database system. Not that it can't be argued that it - still - does "hard-code" MySQL, in 2.0, but IMHO the way to take is forward, not backwards.
As a small example, we have users who honestly hate MySQL, and love Postgres. SQLite support is quite painful, but as possible, we will try to keep it for those hosts that don't offer MySQL... there seem to be a few out there, still, or personal webservers.
Quote from: Labradoodle-360 on September 28, 2011, 03:35:42 PM
At least make the install script smart enough to delete the other database system files.
I thought it already did. I guess I'll have to double-check.
Quote from: Labradoodle-360 on September 28, 2011, 03:35:42 PM
I do agree some noscript stuff should be implemented, but not to the point of restricting the functionality of jQuery and what it can do.
I don't mind requiring JS for extra functionality, but basic functionality shouldn't break just because something went wrong with the JS. That adds a whole ton of fragility and dependency on the client being sane with JS. It also can hurt search engines indexing your site.
Quote from: Labradoodle-360 on September 28, 2011, 03:35:42 PM
You can use functions such as is_int(); or is_string(); to determine whether it's an int or a string, and there are others for different types of course, so yes, it's easily possible. Just some validation and error throwing if it's not inside of one of those.
I believe that's what is done at the deep level, but how do you know what datatype to check? Wouldn't it be simpler to pass the object through a validation function that checks the data is of the type of which it is tagged as being? I wouldn't want to have to add a ton of those types of checks everywhere the data is used. Also, by experience, developers are lazy. If it's not enforced in the framework, data type validation will be overlooked simply by forgetting to handle it.
Quote from: Labradoodle-360 on September 28, 2011, 03:35:42 PM
Although there are a lot of link shorteners, Facebook still has a blacklist check afaik.
Sure, but they have a ton more resources than most forums. Also, if you wanted to be extra-safe, you'd have to look at what's behind the shortened URL, but a lot of shared hosts restrict the kinds of functions and access that would be needed to do so.
QuoteI believe that's what is done at the deep level, but how do you know what datatype to check? Wouldn't it be simpler to pass the object through a validation function that checks the data is of the type of which it is tagged as being? I wouldn't want to have to add a ton of those types of checks everywhere the data is used. Also, by experience, developers are lazy. If it's not enforced in the framework, data type validation will be overlooked simply by forgetting to handle it.
No, just for database insert queries, it would run each variable through a check for data type, which it already does...you can just automatically find out it's type, rather than having to declare it.
It's really not a huge deal, just a small change really. Not a ton of benefit, but there is some.
Quote from: Labradoodle-360 on September 28, 2011, 07:51:09 PM
No, just for database insert queries, it would run each variable through a check for data type, which it already does...you can just automatically find out it's type, rather than having to declare it.
But if you don't know what type it should be when handling it, looking at what type it is currently is pointless. Type checking isn't just about avoiding SQL injections. It's also about maintaining data integrity and avoiding other security issues due to the weak typing PHP has. If PHP was strongly typed, this wouldn't even be a discussion.
In regards to Labradoodle's replies: I understand the reaction well lol, as there is no fixed view on what SMF should be..its not "simple", not anymore anyway, nor is it bloat-free, lots of things not related to forums have been added since 1.0. So i guess its more "add popular mods and optimize" sort of thinking going on.
In that respect anything goes, as long as its popular as mods ;D..so, do we see a gallery, Online users Today, Facebook integration etc..? ;)
And having a smartphone template-set, please. It might not be important to show which phone you posted from, but it IS important to have a better experience on smartphones. Going with sidebars (as posted elsewhere) will only make it even WORSE to surf SMF sites on a smartphone.
Yes I know the sidebars are quite horrible on a smartphone, but the drops just don't work at all with touchscreen. Curve itself was never designed for smartphones and wont scale well to very small screens anyway. I agree we need something better.
really? The dropdown menus work just fine on both my android and my iPad
They work fine on my iPhone...
Quote from: Kindred on September 29, 2011, 07:27:47 PM
really? The dropdown menus work just fine on both my android and my iPad
How do you get them to work? The guys at my forum said they were useless on touch screen. You can get them to open by hovering over the link, but you can't actually use the sub-menus.
I don't have a smartphone - yet :P but if it works I assume the menu stays long enough for people to press the submenu?
Actually, on touch screens, a single tap brings down the menu, the second touch selects the option.
Works just fine here and on facebook
Ah. :) so it will not disappear until you press the option..? or does it by a time-limit? If so, then theres no need to actually make the menu persistant, which I thought must be done for smartphones. The idea I am exploring is a sort of sliding down, stay, or sliding up again. Not so much dropdown as such.
How can it do that? Tapping the link in the main menu should take you to profile, admin or whatever. It can't do that and open the submenu.
Well, the behavior for me is
1 tap opens the sub menu
A second tap triggers the normal effect of the heading or of the sub menu item
Same here...although I think it responds as more of a "firm click" as the link, and more of a tap to the drop down. I don't really think about it when navigating, all I know is that it works just fine for me.
Weird. Maybe they have improved the touchscreen interface since my lot were grumbling. Offhand I can't think how they coded that one. Maybe it detects display:none or absolute/relative positioning on nested lists. Interesting.
Good stuff anyway. Nice to know drops with work without js on touchscreen.
Quote from: Labradoodle-360 on September 30, 2011, 05:59:34 PM
Same here...although I think it responds as more of a "firm click" as the link, and more of a tap to the drop down. I don't really think about it when navigating, all I know is that it works just fine for me.
*nods* I suspect its more behaviours on phones, for example sliding your finger makes it scroll. They prob. tailored these into logical patterns when seeing a regular webpage. So "tap" is the same as hovering, and "push" the same as click.
But is this the same over all phones? Or even in different browsers on the phones?
Quote from: Kindred on September 30, 2011, 05:57:07 PM
Well, the behavior for me is
1 tap opens the sub menu
A second tap triggers the normal effect of the heading or of the sub menu item
Come to think of it, what about the line height? With the default menus the links are stacked very close together. Far closer than is recommended for easy use with fingers.
Use your nails. :) Really, thats what I tried when I was testing a friends phone some time ago.
But again, it might be that the "hit area" is increased when its very tight.
Bottom line: I think the documented advice on how links etc. for touch screens are to be constructed, should be followed, and not using any hacks to make it better. The medium knows best what it can do, the webpage should only adhere to what it absolutely must require from that. Physical things, like width, would be important.
Well yes that's fine if you have nails long enough, but what if you're a tradesman with big fingers and very short nails?
Agree about no "hacks", although it would still seem sensible to use recommended finger-proof link sizing when constructing smartphone themes. IIRC they usually say everything should be at least 44px by 44px to be safe..
It is tough to pick which menu item you want to click, I often click the wrong one without zooming in.
D'oh. I forgot about zoom. That's an obvious workaround but it would be a nuisance.
Okay, I'm out of the house and when checking this topic I decided to actually test it on my iPhone.
Results:
- Clicking a menu with no children will result in going to that link immediately
- Clicking a menu with children will not take you to the parents URL.
- To go to a link, when the item has children you have to double-click the parent element.
- Tapping / Click makes no difference to the result.
Ah. Interesting. I'm still curious about what they are using for detection though.
Hey!
I didn't read the whole topic, sorry if I miss something that was already discussed..., but I'd like to share my feedback with you all as well.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Database Support:
In my opinion, SMF should just support MySQL, or have the option to select their database type on the installation.
I think this is not that relevant, I don't how is the percentage of forums not using MySQL, however certainly the bigger part of the "cake" uses MySQL. If SMF could be adapted to a object-oriented scheme, this would be much easier to handle and other SGDBs could be supported in different packages.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
Calendar:
I believe the Calendar should not be a core-feature. I think it should be removed from the SMF Core, and completely re-written to have an AJAX/jQuery fancy interface, provided as an official addon/modification.
As calendar, I also would like to recommend the same to other functionalities. I believe SMF collects information how forum's owners use its functionalities, the less used could be made available as official modifications.
Quote from: Labradoodle-360 on September 20, 2011, 06:56:32 PM
$smcFunc & PDO:
$smcFunc should be re-written as a PHP Object for easier usage, and a much shorter line-count to accomplish a much better result. Plus some more automation such as auto-data type with the ability to over-ride? For instance, with $smcFunc in 2.0, you have to declare each columns data type, such as 'field' => 'int', and so forth, but this can be figured out with PHP very easily, with no need to declare each column.
Along with the PHP Object, PDO should be implemented for data sanitation.
100% agree with this one.
Another thing that I would like to see implemented is a modular MOD structure, something alike WordPress. MOD incompatibility can become a pain in the ass to those that don't know anything about coding, I believe this would be a great improvement for SMF.
My 2cents.
PS: Sorry about my english, but I am barely awake now...
Quote from: Kindred on September 22, 2011, 07:10:44 AM
Recaptcha is useless now. It was broken by the spambots several months ago.
damnit, where' sthe like button. Oh well, +1
I agree with many of the OP's suggestions but would definitely like to see the old gif's finally put to rest and replaced with png's.
Although I have went through rc2, 3, 4 and 5 and replaced all images and altered all files to make my SMF sites and themes 100% png, it does take time to accomplish so I finally gave up on doing so for 2.0 and 2.0.1.
But all png images does make for a much cleaner look when it comes to theme alterations. And, since SFM does not contain any real large images (other than main_block.png) but mostly small images/icons, an all png SMF should not make much of a difference as far as load times. At least not in the experiences that I have had with an all png SMF install.
;)
QuoteFile Based - Database Modifying - Menu:
There were huge benefits with the move of the menu from template files in 1.1, to Source side in 2.0, however this still could be much more customizable for forum admins who do not know any coding, and even for those who do, much more simple and quick.
The solution is a file-based, and database driven modifying for the menu, with a very customizable and easy to use interface in the admin panel. (Menu Editor Lite + some features of full)
You know how i found this thread? By searching for "menu", because i have searched all of my forum files for over an hour and can't for the hell of it find the place where the buttons are managed. (Wanted to add a button of my own and make a few changes...)
So, though i don't know what exactly he has in mind, i really agree with the thread-author on this one!
Love this thread. Agree with all especially those gif icons. LOSE IE6 support! Support only back to IE8
We had already decided on that anyway. :)
I agree with most of the suggestions but the smf staff are quite lazy these days with new features.
We're not lazy with new features.
Quote from: Labradoodle-360 on April 03, 2012, 10:38:25 AM
Maybe we should split this topic...it's gone off topic for a while.
We were blabbing about the menu system's compatibility with smartphones, that seems pretty next-SMF to me.
But, about removing the other DB systems at installation, what if users want to switch in the meantime? Dunno if anyone wants, but really.
Also - What about upgrading? Does the Upgrade script again remove the obsolete files?
I also think the blacklist feature should be posted as official mod. Not all users want/use that functionality.
And the Spell Check feature... I think that you can remove it. As you said, most modern browsers include spell checking right out-of-the-box anyway (excluding IE). Maybe release it as an addon for these that still want it?
Just my two cents.
Sure, it is. But it's not the goal of this topic to discuss Android and iOS issues with SMF right now :P
I've spent 20 minutes reading this topic salivating at the prospect of some of these ideas for my smf forum.