Hats off to our magnificent Dev & co. for the amazing website.

It's nice to have an SEN that's part of the 21st century, but what about the second decade of the 21st century? We're talking mobile mobile mobile! That's right turns out many people browse this website on their smartphone. While I see no problem with walking around like this, others have complained that attempting to surf SEN with more than just a thumb is unacceptable. They may or may not work for Microsoft's Windows 8 marketing department.

In any case, our lovable mod of the people Roy has taken it upon himself to dare suggest that he would be willing to develop such a feature for SEN. With such a powerful tag team what could possibly stand in their way!

But what do YOU think? What would you like from a mobile SEN? Ideas, pictures, and charitable donations to our Moose fund are all welcome.

I find that many mobile sites downgrade the user experience by not offering all of the features available in the desktop site.

Mobile SEN should just be the Shoutbox.

do I win design phase?

I agree.

I think SEN is, for the most part, simple enough .. it's just a matter of making it so everything scales correctly (like the users online bar not filling the screen when trying to read certain parts of the site that are tiny, or the shoutbox being goddamn huge).

That sounds like a great suggestion. So if we were to have a mobile version of SEN, you would want it to be full-featured. Thanks for your input



The actually design is up to the developers (in this case Roy). Would it be fair to say you support a similar look and feel to the desktop version, but with tweaks and adjustments to make it more accessible to mobile devices?

Add one more tab for forum browsing or thread creation in null and I'll find you with minerals

SEN needs a mobile design. That's all I'll bother to say. Just need a working mobile/desktop mode switch button.

SEN is already pretty mobile friendly so it would be a waste to create a new one. Why not just correct the few flaws there are and have a single, more easily maintainable, platform? Just fix the members online and make a new skin that zooms mostly everything, and we're good. A mobile skin would necessitate an easy way to change or swap skins, to quickly change from desktop to mobile mode, kinda like the SC1/SC2 buttons from SEN v5 (except done right). Or make it auto detect the client (Phone/Desktop/Tablet/etc.) and enable users to configure different skins for the detectable modes.

Mobile SEN could also be an app that gives access to the shoutbox. Maybe add PMs and games if you want.
That would be adding a new value, instead of having 2 nearly identical SENs.

And if all that sounds bad, do whatever you want with mobile SEN as long as it doesn't affect the desktop version.

If a statement of mine is desired, here is what I think today:

When I was developing SEN v6, I did ask myself the question about "mobile version, yes, no & how?".
I had the deadline of SEN's anniversary and thus lacked the time to actually create a whole new system for mobile phones; so instead I tried to make SEN as mobile friendly as possible (I do see the problem of the "Membes Online"-bar. Sorry for that.) and I am confident that this site works pretty reliably on that matter.

As time passed, I have come to think about how I would implement a mobile version and I have an idea about how to integrate that sub-system into the current one. It actually is quite interesting, but I will need to read into several stuff, for example "how to identify smartphone connection reliably via PHP" (if that even is possible, but I think it is.). Up next are screen sizes, how to maintain the AJAX system when you lose connection in between (you might have noticed that sometimes, when you just open the mobile-browser and try to shout, it will not work. I guess that is what happens when the JS polls the server but cannot contact it properly. But more research has to be done) for example.

The current Skin-System would allow to easily implement mobile-versions of the skin (as in every skin could easily have its mobile verison), dividing every skin-class into two major functions: get_html() and get_html_mobile(). The former function holds the entire HTML-Document with some placed coding-words which are replaced with content by the kernel, for those who are interested. The latter function would be like the former, however with eased HTML-Structure and less links, graphics and the like. Mobile-friendly, basically.

What's left are the HTML-Parts of the specific scripts, but that would work similar.

So it -would- be doable without "screwing" the system as in it would look like it all has been wanted to be like that anyways. Cool code. Heh.

Limited functionality is a general problem with shrunken websites for mobile-phones, but it does not have to be.
After all, you can have like a main navigation with few important links but have one link called "All Links" or "Site" or similar which just opend a whole page of a collection of all links. Easily clickable links, of course. Still, every page on its own might be limited. For these cases, we could offer "Change to Desktop-Mode"-services, treating the phone as a desktop-computer until no longer desired.

So, what would else do we need?
After expanding the skin and script classes, we pretty much only need a better javascript. And I want to create a whole new javascript system. A well organized one. Last, but not least, core-classes might have to be adjusted. At least our core-class that creates the console for writing posts and stuff.

Summary time:
We need a subdomain (maybe), the ability to identify mobilephone-connections, expanded skin-class (low work), expanded script-classes (high, but interesting work (What limited "data" shall we show? Questions like that )), new javascript (high, but also interesting) and small kernel adjustments.


Look, you now know a bit of SEN's internal organization!
I am interested into other organizations for websites. There are reasons to like and reasons to dislike that organization.
Who knows what the hell I will be doing in v7, if I ever do one.

Post has been edited 1 time(s), last time on Feb 12 2015, 2:38 am by Devourer.

1) Bootstrap
2) Json
3) Ember, Angular, or even Knockout
4) Ratchet
5) Sammyjs
6) jBBCode or the PECL BBCode Extension

This is the path to modernizing, cleaning up, and improving the performance of SEN: responsive design, lightweight Ajax requests/responses, a client-side MVVM framework, WebSockets to push events, a routing framework, and a non-homebrewed BBCode implementation.

too much hipster I don't even -

Hipster overload aint nothing wrong with coding own stuff for fun; it's sen :<

Bo, really. Could probably use them.

Nothing is more hipster than rolling your own solution.

There's something very wrong with coding something that has already been soundly implemented (and widely used; "mainstream", in fact, the opposite of the word you happened to choose), especially when everything is buggy and broken and you can't seem to find the time to fix it; can you dismiss jQuery on the same grounds? Until everything on the first post of this topic is crossed off, you shouldn't be rationalizing any of this behavior, unless you believe SEN to just be your plaything and not what I believe it to be: a community.

Maybe you didn't actually look into any of the libraries I linked, so I'll go into more detail.

1) Bootstrap

This is the leading framework for mobile-first responsive design. The only competition I know is Foundation. I've used both, and I prefer Bootstrap, hence the suggestion. You can just use the base CSS file and then make tweaks with a separate stylesheet to suit your needs, or you can use Less/Sass to compile down your own custom CSS on top of the existing framework. This will eliminate the need to make a gimped secondary version of the site (which would run into its own issues as things currently are, due to how the Ajax functions work; see below).

2) Json

I hope I don't need to explain this one. The fact that the server is generating and returning HTML markup is appalling. It's bloated and therefore slower and uses more bandwidth, and considering we're doing short polling for every update on the site, plus the buggy client-side navigation, it's a huge waste. Everyone who uses Ajax uses Json.

3) Ember / Angular / Knockout

This ties into Json: by having an MVVM framework, you can update the HTML much easier by updating your JS models. Right now there's basically no organization as PHP spits out HTML for the JS to cluelessly insert the markup into a predetermined location located using a jQuery selector. It could be as simple as having an object in JavaScript that automatically updates the UI when you make changes to it, so removing, editing, and adding HTML becomes trivial, rather than a mess. I've personally only extensively used Knockout, which is much lighter than the other two frameworks (Angular being the framework endorsed and used by Google). All of these technologies are used by tech companies and people that know what they're doing.

4) Ratchet

WebSockets would just greatly improve efficiency on the site. My browser starts lagging when I leave a tab of SEN open for too long because the short polling is flooding my developer tools' network logs. I've used the ASP.NET equivalent of Ratchet (SignalR), and it's definitely something worth having: the site will be faster and we'll see updates sooner. Plus it may eliminate bugs where the JS dies because the polling script times out.

5) Sammyjs

Sure, this is a hipster library, but only because having a single-page application with client-side navigation is a hipster approach to building a website. And the system we have in place now has bugs that seemingly cannot be resolved. Serious bugs, like screwing up the page history and having an unresponsive back button. Just use a library that has been unit tested and has thousands of user testers. I've only used Sammyjs briefly as a complement to Knockout, because I never really had an interest in single-page applications.

6) jBBCode / PECL BBCode

This one probably doesn't need much justification. Try to count on both hands the number of BBCode bugs we've had since rolling out v6 and you'll find it to be impossible. Moreover, the code is a mess, and it uses Regex, which is slower than both suggested implementations. Considering we parse BBCode for everything on the site, this seems like an obvious improvement. Moving to a proper library for BBCode also makes it possible to easily extend it, so we can add more features and make a better overall experience for our users.

But if you want to go the hipster route, get off of PHP, because it's a terrible language. Use Nodejs for the backend.