Wedge
Public area => The Pub => Features => Topic started by: Nao on March 15th, 2012, 08:55 AM
-
Another minor feature that I've been thinking of for a few days, is the ability to allow for multiple default skins.
It's easy really.
- Default skin for guests
- Default skin for new members
Until now, easy to grasp... But even easier:
- Default skin for mobile devices
This would allow for Wedge to use the 'Wireless' skin by default on iPhones and company, and admins would be able to install Dragooon's Wedge4Mobile theme, and then choose his theme as the default mobile skin as a replacement for Wireless, if they think it's too limited in terms of usability.
I'm sure we could also think of other opportunities to set a different default skin, but for now let's focus on mobile.
Yesterday I went to sm.org, wondering if someone had already thought of it, and indeed emanuele posted a similar mod last month, so I thought it was worth mentioning, just in case I get accused of stealing an idea -- I did think of it by myself, but I also acknowledge that I'm now aware there's a working implementation at SMF :P
I was curious and looked at the detection code (wanted to see if it differentiated between iOS devices and used any tricks to retrieve resolution, such as Ajax polling or a small redirection via JavaScript -- not so much), it's an open-source external script that's being used, I'm just surprised that it can take 32 kilobytes just to detect a mobile device... Oh my :lol:
Wedge does it in a single line, but obviously it's certainly not as extensive!
-
I have a fairly simple mobile detection code that doesn't take more than 30 lines. Not really extensive but works fairly well.
-
Well, could definitely use that ;) I'm especially interested in speed (since we'll be running that code even on desktop) and strictness, i.e. ensure the device IS confirmed to have a smaller resolution than usual, e.g. testing for iPhone or iPod Touch or Android but remove devices that have a higher resolution e.g. Galaxy Note has a small screen but is good enough for normal browsing AFAIK, so where should it go?) instead of just ensuring it's running iOS/Android/etc and isn't a tablet...
-
That level of checking can be best done via CSS media queries. I treat Note as a mobile device and let my theme handle the splitview or single view dilemma, since at the end of the day it's a touch device. Here's the code that I use
$user_agents = array(
array('iPhone', 'iphone'),
array('iPod', 'ipod'),
array('iPad', 'ipad'),
array('PocketIE', 'iemobile'),
array('Opera Mini', isset($_SERVER['HTTP_X_OPERAMINI_PHONE_UA'])),
array('Opera Mobile', 'Opera Mobi'),
array('Android', 'android'),
array('Symbian', 'symbian'),
array('BlackBerry', 'blackberry'),
array('BlackBerry Storm', 'blackberry05'),
array('Palm', 'palm'),
array('Web OS', 'webos'),
);
foreach ($user_agents as $ua)
{
$string = $ua[1];
if ((is_bool($string) && $string == true) || (strpos(strtolower($_SERVER['HTTP_USER_AGENT']), $string)))
/** Do mobile theme stuff **/
}
-
That level of checking can be best done via CSS media queries. I treat Note as a mobile device and let my theme handle the splitview or single view dilemma, since at the end of the day it's a touch device. Here's the code that I use
BTW, PocketIE is a PocketPC program and as such, very old stuff. I think using 'IEMobile' would be smarter, as it accounts for Windows Mobile browsers.
-
- Default skin for guests
- Default skin for new members
Until now, easy to grasp... But even easier:
- Default skin for mobile devices
Also: option to disable users picking their own (which is a shade cleaner than having to remove skins)Hmm yeah that's the thing -- philosophy differences. A mobile device can either be seen as a "device without a mouse or keyboard" (i.e. you need to redo the UI), or a "device with a low resolution"
I do get the impression that the mobile support should be handled less by a skin and more by a theme (bearing in mind that we can fall back to the default)
-
Works for me.
Also: option to disable users picking their own (which is a shade cleaner than having to remove skins)
The main reason I never worked on these, is that it's pretty much impossible to put these variables into skin.xml because it means admins have to edit them manually, which is precisely what I want to avoid (so that they can easily upgrade their site later...)
So it has to be done in the admin area, something like having a variable that specifies skin paths to ignore... But I'm not big fan of that either ;) If only because I like the idea of skins being so flexible that, like plugins, you can immediately add or remove them through FTP and they'll be usable or deleted immediately. (Hmm, actually I never tried deleting a skin while it was being used... should try that.)Yup. Though most current mobile devices subscribe to both camps; almost all mobile phones are both, most tablets are the former, but you can get keyboards for both.
I do get the impression that the mobile support should be handled less by a skin and more by a theme (bearing in mind that we can fall back to the default)
-
You mean, adding a per-skin option like <disable> and <hide>, right...? (disable = not selectable, not usable, only used for inheritance. hide = not selectable, but usable through e.g. default skin selection.)
Except it's very unlikely you'd do that. (There's only the Asus Eeepad Transformer/Transformer Prime that does that on a wider scale, AFAIK. These definitely qualify for full desktop experience to me.)
Well, mobile support is included in our default theme... Considering that it's less than 30 lines of code or so, I don't think it's that big a deal. Do you?
The reason I'm so adamant about mobile support being a theme and not a skin is as indicated the reduction in bandwidth (and, if we're careful, there's no reason why we couldn't trim certain data we're not showing from even being queried in the first place)
-
So... This morning I worked on (finally) adding a separate mobile theme setting to Wedge.
*Normally*, if everything goes well, you should be getting the Wireless skin by default if you visit Wedge on a smartphone or tablet (I know -- with the iPad 3 now sporting a larger resolution than most desktop monitors, it sounds silly to include that in the mobile mode as well... probably should add some media queries to compensate a bit...), and the Weaving skin by default if you visit it with a desktop browser. These two settings should be independent, i.e. you can set Weaving in mobile mode and set Wireless in desktop mode, although there's little point in doing that, and I don't think one can select their mobile skin for now. (I haven't tried... I'm pretty sure it won't work though :P)
Just wanted to know if it works for you...
(It works on my iPod Touch, obviously it'll work on any iPhone too.)
(Two quick ways to confirm it's Wireless: the font is bigger :P, and forum posts have the avatar on top rather than on the left/right.)
-
Confirmed working on iPh4 as you surmise ;)
-
Working on Android ICS (CyanogenMod 4 on SGS II, default browser and Sleipnir tested).
-
Working on a stock Droid X.
Looks great.
-
Works fine (Android 2.3, both stock browser and Opera Mobile tested), but the default font size could be a tad bigger.
BTW: Here(http://code.google.com/p/php-mobile-detect/) is a very reliable, still relatively lightweight PHP class for detecting mobile devices. It pretty much detects everything you throw at it.
-
Works fine (Android 2.3, both stock browser and Opera Mobile tested), but the default font size could be a tad bigger.
BTW: Here(http://code.google.com/p/php-mobile-detect/) is a very reliable, still relatively lightweight PHP class for detecting mobile devices. It pretty much detects everything you throw at it.
The code is also very, very tight now...
<?php
/**
* Wedge
*
* Mobile browser detector. Very simplistic code, based on an early version of Mobile_Detect (MIT license).
*
* @package wedge
* @copyright 2010-2012 Wedgeward, wedge.org
* @license http://wedge.org/license/
*
* @version 0.1
*/
class weMoDe
{
protected $devices = array(
'Generic' => 'mobile',
'iOS' => 'iphone|ipod|ipad',
'Android' => 'android',
'BlackBerry' => 'blackberry|rim tablet',
'Symbian' => 'symbian',
'Windows' => 'windows ce|windows phone',
'PalmOS' => 'palm|avantgo|plucker|xiino',
'Others' => 'kindle|silk|playstation|nintendo|wap|up.|bolt|opera mobi'
);
public function isMobile()
{
if (empty($_SERVER['HTTP_USER_AGENT']))
return false;
$ua = strtolower($_SERVER['HTTP_USER_AGENT']);
if (isset($_SERVER['HTTP_PROFILE']) || isset($_SERVER['HTTP_X_WAP_PROFILE']) || isset($_SERVER['HTTP_X_OPERAMINI_PHONE_UA']))
return true;
if (isset($_SERVER['HTTP_ACCEPT']) && (strpos($_SERVER['HTTP_ACCEPT'], 'text/vnd.wap.wml') !== false || strpos($_SERVER['HTTP_ACCEPT'], 'application/vnd.wap.xhtml+xml') !== false))
return true;
foreach (explode('|', implode('|', $this->devices)) as $device)
if (strpos($ua, $device) !== false)
return true;
return false;
}
}
?>
However, by now I'm not even sure this is the 'right' thing to do anymore.
Because what bothered me in the first place was: inability to store the result in the database (because, basically, your account isn't tied to your browser), or a cookie (I like it to stay as short as possible really...), then it struck me that I could simply use a session variable for that... 'Eh.' Actually, I've never (ever!) used $_SESSION before to store anything in my own code, but I should do it more often -- if only because it acts as a secondary cache where I can put complex calculations that don't need to be done on every single page.
What do you think...?
I've rewritten my (short) code to use the session. Seems to work. Maybe I should switch to Mobile_Detect 2.x and use sessions for it...
-
A session variable is probably the best way to store such short lived objects that have no business in the database. Cookie would probably work equally well, but with all the madness about cookies, it's probably best to avoid them when possible :)
Besides, how often do sessions expire? Shouldn't be a problem to run the detection code every 15 minutes (or so).
P.S. Just noticed. I can like my own posts. Intentional behavior?
-
Liking your own post, it's something the code never cares about, but since there's no configuration for it at present, that's the sort of thing that would typically be configurable ;)
You're right about session variables, and IIRC they expire after 20 minutes in SMF/Wedge by default. Though I should note I have made distinct noises about removing sessions for guests across the board (because I don't think you really need much in the way of sessions for guests for the most part, and the rest is just for snapshots of analytical information, rather than meaningful information, IMHO)
I'd rather avoid cookies for that sort of thing, laws aside, just because they have a habit of living longer than expected, and carry an overhead per request.
-
How about letting the browser cache some php generated content on a mobile theme?
I have done this on one of my mobile templates. You have to have a set of rules, but not that hard. Here is a basic of my rules.
Locked Topic - Cache for a week
Multiple Pages where the current page is not the last one - Cache for a day
All other likely to change - Cache for two minutes
This makes it easier on slow data speeds when you need to navigate back and such and don't want to page loading reloading all the time.
I also turned on compression for most smart devices, since they usually support compression. This is something SMF had turned off by default for all mobile devices.
On my mobile theme I am using jQuery Mobile, works pretty good, don't expect you to do the same just throwing that out there.
-
A session variable is probably the best way to store such short lived objects that have no business in the database. Cookie would probably work equally well, but with all the madness about cookies, it's probably best to avoid them when possible :)
Of course it also means that if we disable sessions, a guest will have to re-run the test on every page... Which isn't cool. So maybe we could have 'emulated' sessions in the database (i.e. per IP.)
But I know Pete is gonna kill me... :PP.S. Just noticed. I can like my own posts. Intentional behavior?
-
If you want to remember a user preference for a guest, a cookie might be better in this case, because it's not something that needs to be stored, and still falls into the definition of 'remembering a user's preference', though it's complicated and depends on how you define 'persistent' for things like that.
SMF does other things like that with cookies, like remembering certain preferences for upshrinks and so on, I see no reason why we couldn't do the same for guest themes, which will still be more efficient than creating a session in *any* form, regardless of how it's created. (Oh, and no, IP session is still a bad idea, and I'd rather keep the current setup than go down that road the more I think about it)
-
I thought you didn't want to have non-critical cookies because of the ICO law...
-
I don't. However, there is an entirely separate, justified use case available for 'remembering user preferences', and the example given by markham of how it can be done is really quite neat.
-
Must have missed that.
And if it's 'possible' to store is_mobile in a cookie, then yeah, I suppose we can do (isset($_SESSION['is_mobile']) ? $_SESSION['is_mobile'] : (isset($_COOKIE['is_mobile']) ? ...) or something like that...
The cookie would have to be short lived, though. Because what if you switch to desktop mode immediately...
-
That's exactly it - if the user wants to indicate that they're using a mobile site, it can be handled as a preference, and done infinitely better than the old ?wap / ?wap2 / ?imode
I seem to recall that was in no small part how Dragooon's theme worked.
-
Technically, I dunno if you looked into it, but this is how Wedge does it:
- Checks for the session var, if not, sets it <- determines whether the current device is a mobile one.
- If mobile, uses id_theme_mobile and skin_mobile from the DB. Otherwise, uses id_theme and skin.
- User is now free to change skin_mobile etc. while browsing (Profile > Change skin)
- So, basically -- you can browse in a desktop skin while on a mobile device, then switch to your PC and browse in a mobile skin, because it's not the same session ID and thus it automatically recognizes you want to use id_theme this time, which can also be set to use a mobile skin...
I could commit all of this right now, but I have yet to write the UI for selecting the default mobile skin. (Right now it's skins/Wireless, which is going to ship with Wedge anyway, so it's not much of an issue but one might want to use another default...)
Unless you want to do it, ah ah. I just don't have the time this weekend to do anything too big in Wedge...
-
I won't be looking at it this weekend, I'm using what time I have to get other stuff done, seems like I'm always chasing the clock :/ It's also code I'm not that familiar with.
-
Chasing the clock... And my posts :lol: I can barely keep up... And I haven't even had time to find the place where we discussed the action bar... Oh let's do it here: so what do you think, after a day of use...? Does it feel natural, or not? I'm not sure myself. But I certainly think it's something I should keep exploring. As for the checkbox, yesterday it was next to the action bar but I moved it back to the header because it took too much space, and I like having that checkbox look like a 'pin' on the side of a post.
-
It certainly feels a bit more natural, especially with the quick edit button there as well. Though having quite a dark line either side of it does break up the post + action bar + signature a bit much.
The problem with the checkbox where it is right now, it seems like it's just random and out of place.
-
You guys are talking about the area on the right of this post right?
IMHO it feels too empty in that area, especially on long post. Maybe reorganize it and when the user scrolls have the bottom part break off and scroll with the page. Like the thought system can scroll down with you so you can have quick access to it at any time. This is just my opinion though.
-
It certainly feels a bit more natural, especially with the quick edit button there as well. Though having quite a dark line either side of it does break up the post + action bar + signature a bit much.
And removing the bottom line is also a problem.The problem with the checkbox where it is right now, it seems like it's just random and out of place.
@nend> Nope, that's the sidebar... We're talking about the action buttons (Quote, Modify, More...) below the post.
As for what you're suggesting -- it would only be possible if the sidebar contents was smaller than the height of your viewport... Which is hardly going to be the case most of the time...
Heck, that's why I added that subtle gradient in the sidebar. So that you have something to stand for the sidebar when you scroll down too much... And not many websites take balance into consideration :P