What is the difference between skin and theme?
I have looked at this articles:
https://en.wikipedia.org/wiki/Skin_%28computing%29
https://en.wikipedia.org/wiki/Theme_%28computer%29
and there is only one difference: theme is less "complicated" then skin. Like different set of icons and colors in theme, but skin can change UI control appearance (checkbox vs switch for ON/OFF control) in programmatic way which can be done by styling/CSS.
That difference in answer if it applied to WEB-app vs desktop application?
UPDATE. I have added the ability to change the look of the program via configuration file (icons, colors, element position). Is that skin or theme?
I would say the difference is minor. My gut feeling says that I would call something which alters the appearance and feel of an interface a skin while I would call something which only alters the appearance a theme. A skin could add an extra button to allow for easier access to some of the underlying program's functionality, for example.
I have added the ability to change the look of the program via configuration file (icons, colors, element position). Is that skin or theme?
That would be a theme (by my logic). In reality, though, most people will use the two terms interchangeably.
A Theme is a combination of multiple features that not only defines the layout of the website but also add additional features to your site. So a theme may consist of combination of skins and modules.
Whereas Skin is something that is purely related to your website appearance like it's color, block placement and other factors related to its layout.
UPDATE. I have added the ability to change the look of the program via
configuration file (icons, colors, element position). Is that skin or
theme?
I would agree with #timgeb that you are actually configuring skin of your theme.
Related
In frustration of some breakage, I've nuked my old/ancient
version of Scite, and done a fresh install of Scite.
So, on Windows, I now have 32-bit version 5.1.4.
Three issues:
#1 How/where to change the overall (not file-type specific)
background color, it defaults to WHITE. I'd like to configure it to that light-yellow-ish color. How/where to
do that. (Googling said to change it in the "SciTEGlobal.properties" file, but nothing in there resembles what I'm trying to do. !?!?)
#2: So, specific to HTML files, as I scrolled down thru a file, the background in HTML sections would have this same light-yellowish color, and the JS sections had white background, and I'd like to have something equivalent
to that. (On the defaults I see now, html sections are white, but the JS section are an off-white, but they are
so close to white, that my eye can hardly discern them, unless I tip the laptop's screen back and forth. (Yuck.)
#3: A new behavior I see now, is that there is some scheme for html, that uses different font-sizes for different contexts. While that seems like a worthwhile feature for many, I'd like to go back to what I had before...where
all lines were the same font-size. (And then, how can I specify just one single font-size, for all lines in all file-types.)
TIA...
Dave
Default background color and style can found in SciTEGlobal.properties file
# Global default styles for all languages
# Default
style.*.32=$(font.base)
# Line number
style.*.33=back:#E7E7E7,$(font.base)
To change default background color open SciTEUser.properties file and add following lines
# Global default styles for all languages
# Default
style.*.32=$(font.base),back:#101010,fore:#BBBBDD
# Line number
style.*.33=$(font.base),back:#101010
Note: Editing SciTEUser.properties file for customization is best practice. However this file is stored under %USERPROFILE% folder (in Windows) and customization limited to that machine only. If your SciTE installation is on USB stick (Portable installation) and you want to retain SciTE customization on whichever PC you plugged in then edit SciTEGlobal.properties
To do any changes specific to any language then edit <language>.properties file.
example html.properties for HTML specific customization.
This is a topic that may be considered something not necessarily "programming related"; however, I feel it is since I'm asking for specific techniques.
Essentially, as a web developer, I work with a variety of platforms that include a WYSIWYG editor in the backend (TinyMCE, WYGWAM, etc) and one of the selling points of such systems is that it becomes easier to manage your own content because of these tools.
In theory, sounds great, in practice, not so much.
It can be way too easy for a client to break a layout by using many of the advanced features of a WYSIWYG editor. They can start floating things, setting too much margin/padding, etc.
Generally, I have tried to build any of these types of pages with only some sensible default styles applied to a few of the most common tags, such as setting a font size, colors, some margins, and some text decorations.
I would like to know if anyone has used anything more advanced to essentially turn the output of:
$cms->getContent();
...or equivalent into something that is effectively sandboxed and operates entirely agnostic of any other style/layout elements being used.
As often as possible, I express to clients that they should purchase an HTML/CSS book for Dummies and read it so that they aren't deer in headlights when they click "code view" in a WYSIWYG. But I know they don't do this, nor do they hire anyone who has experience, and it ends up allowing a client more control than they should responsibly have.
Plus, it sucks when you are using their sites as work samples to show others knowing they have the ability to take your beautiful design and development and make it look like crap.
A few things:
I have a standard WYGWAM config that I reuse on new sites by importing the exp_wygwam_configs table.
I keep options very limited in the editors
Areas of the page delineated for images should use a File field, with an image resizer like CE Image used to insure proper size
Client training. Make videos with Camtasia or similar tool if you have to.
Use a custom stylesheet for WYGWAM that has a small subset of styles, so they can choose h2...h4, for example, but not h1 or h5.
After encountering a lot of issues with WYSIWYG editors (which, by the way, never reflect accurately what you "get" in the end), I now prefer to leave only the most basic formatting features in the editor's configuration. For example, take a look at stackoverflow's editor.
It's got the following features: bold, italic, link, quote, pictures, lists, and alignments. The only special feature here are code sample and html, which are targeted to this site's audience. Most of your client don't need them.
I think it's the best approach, because if you give your clients the feeling that they can do whatever they want in the page, but in the end, this content is filtered when the page is rendered, they are going to be really frustrated. Not to mention the fact that the site will be slowed by the filtering process and the need to put the filtered content in cache.
Sometimes the client indeed wants to have a special layout in a page, but I think that can be best done by customizing the CMS so that it fits the client need.
What are the best practices for customizing themes for a WP7 application (font family, colours, etc)? Should I be sticking to the standard names and replacing them or creating new resource names and using those?
ie. "PhoneFontFamilyNormal" or "MyAppFontFamilyNormal"? "PhoneTextNormalStyle" or "MyAppTextNormalStyle"?
The documentation on the subject seems to focus soley on playing the straight and norrow, even though custom themes are supported (if disueded).
I would personally create my own resources with unique names and use those. This avoids any confusion relating to precedence (I can't recall right now the resource look-up mechanism in Silverlight, I know that it is a simplification of the WPF one - which is a little complex!).
One important consideration is whether you will support dark / light themes. The standard theme resources like PhoneBackgroundBrush will honour the users theme. Therefore, if you wish to support Dark / Light I would recommend deriving your own theme from the standard one, for example, you might derive your background brush from PhoneBackgroundColor.
What are the recommended colors for an application's background, button faces, etc.?
In the past I've just chosen a color scheme but I'd like to be more compatible with the Windows Accessibility Options, etc.
I see that VB6 has System Colors like Application Workspace.
Edit: I'd like to find an explanation of all of those colors (like what's the difference between Application Workspace and Window Background?
In my opinion, you should leave the colors as they are if you are using standard controls; they'll get the right color according to che current color scheme by themselves. You need to use the color constants only if you have to draw your own UI elements; in that case, the meaning of those constants is explained briefly in their documentation.
This PDF http://www.johnsmiley.com/cis18/Smiley009.pdf [ explanation of VB6 System Color values ]should help you. It lists all the system color constants and what they mean. For instance vbApplicationWorkspace is the "Background color of multipledocument interface (MDI) applications."
If you're interested in the whole MS Windows UI/UX guidelines, they are available online here and for download here. Page 618 deals with how to "Use theme or system Colors"
It depends on the language and framework you use. .Net for example has an entire SystemColors class full of static properties like SystemColors.Control that are 'changed' to the corresponding system color in runtime.
I think most office applications conform to the system colors, while most graphics intensive applications (e.g. games) use their own color scheme.
It is best if you try to use the colors of the current system (like the .NET SystemColors), that way if the user changes his settings (for example if he uses a high-contrast color scheme or some fancy black theme he likes) your application will adapt those colors and that way conforms to the users preferences/needs.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.