My words can not describe the thanks that I have for our military. So I have designed an image for today. I hope this says it all. THANK YOU.
My words can not describe the thanks that I have for our military. So I have designed an image for today. I hope this says it all. THANK YOU.
Who does not like a great web site background pattern for their web site? I believe it can make the difference between an okay web site and a web site that has some class and style.There are hundreds of sites available on the web that show you how to make background patterns. There are even sites that will allow you to download the pre-made patterns that you can just drop in to Photoshop Presets folder. There are some classical background patterns that are used quite a lot; such as, TV line pattern, diagonal line pattern, and dotted pattern. These patterns have been over-used. I think if you are going to design a web site then an original background pattern is a must. There are definitely some exotic pattern creators out there as well. I personally like the subtle patterns they can be added to your Photoshop very easily and can be altered without much effort.
Background patterns for web sites can be that little extra design element that makes your site stand out from the rest. I have included some links to sites that I use for background patterns check them out below.
STRIPE GENERATOR (This is a generator that will make the patterns for you)
SUBTLE PATTERNS (This is one of my favorites, love how subtle the patterns are and they even have a plugin for WordPress)
COLOR LOVERS (This site not only has patterns, but color palettes as well and it is a site that allows you to create your own custom pattern)
DOTTER PATTERN (This site is a dotted background pattern generator, pretty useful if you are in a hurry and don’t want to do it yourself)
BG PATTERN CREATOR (This site allows you to basically create your pattern on the site, then you can download the image)
BRUSHEEZY PATTERNS (This site as a wide variety of downloadable images for Patterns everything from Wood Background to Snowflake Patterns)
DIN PATTERNS (You want to talk about Exotic Pattern Creation this site definitely fits that description but it has some class and style in the patterns)
BG MAKER (Wow, now this site is the KING of Patterns over 1685 Pages for a total of 246,633 Patterns as of this Post May 2012. This site not only has this many patterns but also allows to make your own pattern on the site. Another Personal Favorite)
TARTAN DESIGNER (Now, if you’re feeling a little scottish and want a tartan for your web site background then this is the web site for you. As of May 2012 the site has over 123 pages with a total of 615 Tartan designs. You can also make your own custom tartan as well)
ALICE GRAFIXX (Once again this site has plenty to look at just like the others over 64 pages for a current total of 1024 pattern backgrounds as of May 2012.)
In conclusion, no matter the design, style, color, or feel of web site you are going for the 10web sites above offer a wide-variety of patterns and textures. Please feel free to post a comment or suggest another pattern site for this post. Stay connected till next week, when we talk about color and give you some very useful links that every designer should have when choosing a color palette.
HONG KONG—Apple Inc., AAPL +0.27% which is expected to launch its next-generation iPhone later this year, has ordered screens from its Asian suppliers that are bigger than the ones used in iPhones since they debuted in 2007, people familiar with the situation said.
Production is set to begin next month for the screens, which measure at least 4 inches diagonally compared with 3.5 inches on the iPhone 4S, the latest phone from Apple, the people said.
The move suggests that the Cupertino, Calif.-based company is trying to make its popular smartphone more appealing amid intensifying competition from rival Samsung Electronics Co. of South Korea. Samsung, which became the world’s biggest cell phone maker in the first quarter, recently unveiled its new flagship smartphone with a 4.8-inch display, one of the largest smartphone screens.
Bloomberg NewsAs Apple prepares for a launch of a new iPhone later this year, people familiar with the situation say the company is planning for a larger screen. Above, the Apple store in Hong Kong.
Until now, Apple has never changed the size of the iPhone’s screen, which has always been 3.5 inches from the first model that debuted in 2007. For the next iPhone, which analysts predict will come out in the fall, Apple is working with multiple screen makers including South Korea’s LG Display Co., LPL -3.60% Japan’s Sharp Corp. 6753.TO -2.37% and Japan Display Inc., a new company created last month by three Japanese companies and the government, some of the people said.
Apple has also stuck with one size for its iPad tablet, while other manufacturers have produced a range of sizes. The Wall Street Journal reported in February that Apple was testing tablet computers with screens smaller than the 9.7-inch screen on the existing iPads.
An Apple spokeswoman declined to comment.
Apple effectively defined smartphones as a new category with its iPhone, but the market has rapidly evolved and expanded over the past few years and is now crowded with many brands selling smartphones in various sizes and price ranges.
Apple, the world’s most valuable company, faces particularly fierce challenges from Samsung, which sells a much broader variety of phones. The two companies together account for more than half of the world’s smartphones. In the quarter through March, Samsung shipped 44.5 million smartphones to grab a 30.6% share of the global market, topping Apple’s 24.1% share with 35.1 million iPhones, according to market research firm Strategy Analytics.
This year, analysts expect Samsung’s smartphone shipments to double, while the next iPhone is also expected to boost Apple’s shipments.
Samsung said that the Galaxy S III, a new version of its flagship smartphone, will hit stores in Europe this month and in the U.S. this summer. Its 4.8-inch screen is larger than the 4.3-inch display on the company’s current flagship model Galaxy S II. Taiwan’s HTC Corp., 2498.TW -6.59% another major smartphone maker, also has models with screens larger than 4 inches.
A new iPhone with a larger screen wouldn’t necessarily mean that Apple is making changes to its products because of what rivals are doing, said Mizuho Investors Securities analyst Nobuo Kurahashi.
“The smartphone market has become diverse, but the iPhone still sets the agenda,” with the whole industry watching Apple’s every move, he said. He said that the iPhone’s strength lies in the overall experience including its user interface and applications, and the screen’s size wouldn’t be its defining feature.
“If Apple ever released a lower-priced iPhone, that would be more of a sign that the changing market environment is beginning to affect the company,” he added.
The iPhone remains a big growth engine for Apple, and the phone’s popularity in Asia was a key factor behind the company’s robust earnings for the most recent quarter through March. Its profit nearly doubled in the quarter, while iPhone sales jumped 88%.
Aside from their rivalry in the smartphone market, Samsung and Apple have been locked in a legal battle. Apple last year sued Samsung over smartphone design and patents, and Samsung countersued. At the same time, they are dependent on each other as Apple is the largest customer for Samsung’s component divisions, which make key parts for smartphones and tablets such as chips and displays.
Apple doesn’t manufacture its own products. Like many other major consumer-electronics brands, it hires manufacturing specialists—many of which are from Taiwan and have extensive operations in China—to assemble its gadgets, using components made mostly by Asian suppliers.
The goal of a “responsive images” solution is to deliver images optimized for the end user’s context, rather than serving the largest potentially necessary image to everyone. Unfortunately, this hasn’t been quite so simple in practice as it is in theory.
Recently, all of the ongoing discussion around responsive images just got real: a solution is currently being discussed with the WHATWG. And we’re in the thick of it now: we’re throwing around references to
img set; making vague references to polyfills and hinting at “use cases” as though developers everywhere are following every missive on the topic. That’s a lot to parse through, especially if you’re only tuning in now—during the final seconds of the game.
The markup pattern that gets selected stands to have a tremendous influence on how developers build websites in the future. Not just responsive or adaptive websites, either. All websites.
Let’s go over the path that led us here one more time, with feeling:
The earliest discussion of responsive images came about—predictably enough—framed in the context of responsive web design. A full-bleed image in a flexible container requires an image large enough to cover the widest possible display size. An image designed to span a container two thousand pixels wide at its largest means serving an image at least two thousand pixels wide. Scaling that image down to suit a smaller display is a trivial matter in CSS, but the requested image size remains the same—and the smaller the screen, the better the chance that bandwidth is at a premium.
It’s clear that developers’ best efforts to mitigate these wasteful requests were all doomed to fall short—and not for lack of talent or effort. Some of the greatest minds in the mobile web—and web development in general, really—had come together in an effort to solve this problem. I was also there, for some reason.
I covered early efforts in my previous ALA article, so I’ll spare everyone the gruesome details here. The bottom line is that we can’t hack our way out of this one. The problem remains clear, however, and it needs to be solved—but we can’t do it with the technologies at our disposal now. We need something new.
Those of us working on the issue formed the Responsive Images Community Group (RICG) to facilitate conversations with standards bodies and browser representatives.
“W3C has created Community Groups and Business Groups so that developers, designers, and anyone passionate about the Web has a place to have discussions and publish documents.”
Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does. When the WHATWG proposed a solution last week, many of the people involved in that discussion hadn’t participated in the RICG. In fact, some key decision makers hadn’t so much as heard of it.
The pattern currently proposed by the WHATWG is a new
set attribute on the
img element. As best I can tell from the description, this markup is intended to solve two very specific issues: an equivalent to ‘min-width’ media queries in the ’600w 200h’ parts of the string, and pixel density in the ’1x’/’2x’ parts of the string.
The proposed syntax is:
<img src="email@example.com" alt="" set="firstname.lastname@example.org 600w 200h 1x,
email@example.com 600w 200h 2x, face-icon.png 200w 200h">
I have some concerns around this new syntax, but I’ll get to that in a bit.
The markup pattern proposed earlier by the RICG (the community group I’m part of) aims to use the inherent flexibility of media queries to determine the most appropriate asset for a user’s browsing context. It also uses behavior already specced for use on the
video element—in the way of
mediaattributes—so that conditional loading of media sources follows a predictable and consistent pattern.
That markup is as follows:
<picture alt=""> <source src="mobile.jpg" /> <source src="large.jpg" media="min-width: 600px" />
<source src="large_1.5x-res.jpg" media="min-width: 600px, » min-device-pixel-ratio: 1.5" />
<img src="mobile.jpg" /> </picture>
Via Github, this pattern has been codified in something as close to a specas I could manage, for the sake of having all the key implementation details in one place.
To my knowledge, there are currently no polyfills for the WHATWG’s newly proposed
img set pattern. It’s worth noting that a polyfill for any solution relying on the
img tag will likely suffer from the same issues we encountered when we tried to implement a custom ”responsive images” solution in the past.
Fortunately, both patterns provide a reliable fallback if the new functionality isn’t natively supported and no polyfill has been applied:
img set using the image’s original src, and
picture using the same fallback pattern proven by the
video tag. When the new element is recognized, the fallback content provided within the element is ignored—for example, a Flash-based video in the case of the
video tag, and an
img tag in the above
Participants in the WHATWG have stated on the public mailing list and via the #WHATWG IRC channel that browser representatives prefer the
img set pattern, which is an important consideration during these conversations. Most members of the WHATWG are representatives of major browsers, so they understand the browser side better than anyone.
On the other hand, the web developer community has strongly advocatedfor the
picture markup pattern. Many developers familiar with this subject have stated—in no uncertain terms that the
img set syntax is at best unfamiliar—and at worst completely indecipherable. I can’t recall seeing this kind of unity among the community around any web standards discussion in the past—and in a conversation about markup semantics, no less!
While the WHATWG’s preferences, and the web developer community’s differing preferences, certainly should be considered as we finalize a standard solution to the problem of responsive images, our highest priority must remain providing a clear benefit to our users: the needs of the user trump convenience for web developers and browser developers alike.
For that reason (for the sake of those who use the web), it’s critical not to cast these discussions as “us vs. them.” Standards representatives, browser representatives, and developers are all partners in this endeavor. We all serve a higher goal: to make the web accessible, usable, and delightful for all. Whatever their stance on
img set or
picture, I’m certain everyone involved is working toward a common goal, and we all agree that a ”highest common denominator” approach is indefensible. We simply cannot serve massive, high-resolution images indiscriminately. Their potential cost to our users is too great—especially considering the tens of thousands of users in developing countries who pay for every additional kilobyte they consume, but will see no benefit to the huge file they’ve downloaded.
That said, I have some major issues with the
img set syntax, at least in its present incarnation:
Use cases are a list of potential applications for the markup patterns, the problems that they stand to solve, and the benefits.
I’ve published a list of use cases for the
picture element on the WHATWG wiki. It is by no means exhaustive, as
picture can deliver an image source based on any combination of media queries. The most common use cases are screen size and resolution, for certain, but it could extend as far as serving a layout-appropriate image source for display on screen, but a high-resolution version for printing—all on the same page, without any additional scripting.
At present, no list of use cases has been published for
img set. We’ve been working under the assumption, based on conversations on the WHATWG list and in the WHATWG IRC channel, that
img set covers two uses specifically: serving high-resolution images to high-resolution screens, and functionality similar to
min-width media queries in the way of the
It’s vital that we have a way to take advantage of new techniques for detecting client-side capabilities as they become available to us, and the
picture element gives us a solid foundation to build upon—as media queries evolve over time, we could find ourselves with countless ways to tailor asset delivery.
We may have that same foundation in the
img tag as well, but in a inevitably fragmented way.
I don’t mind saying that the
img set markup is inscrutable. It’s a markup pattern unlike anything seen before in either HTML or CSS. This goes well beyond author preference. An unfamiliar syntax will inevitably lead to authorship errors, in which our end users will be the losers.
As I said on the WHATWG mailing list, however, given a completely foreign and somewhat puzzling new syntax, I think it’s far more likely we’ll see the following:
<img src="firstname.lastname@example.org" alt="" set="email@example.com 600w 1x,
firstname.lastname@example.org 600w 2x, face-icon.png 200w">
<img src="email@example.com" alt="" set="firstname.lastname@example.org 600 1x,
email@example.com 600 2x, face-icon.png 200">
<img src="firstname.lastname@example.org" alt="" set="email@example.com,
600w 1x firstname.lastname@example.org 600w 2x, face-icon.png 200w">
Regardless of how gracefully these errors should fail, I’m confident this is a “spot the differences” game very few developers will be excited to play.
I don’t claim to be any smarter than the average developer, but I am speaking as a core contributor to jQuery Mobile and from my experiences working on the responsive BostonGlobe.com site: tailoring assets for client capabilities is kind of my thing. To be perfectly honest, I still don’t understand the proposed behavior fully.
I would hate to think that we could be paving the way for countless errors just because
img set is easier to implement in browsers. Implementation on the browser side takes place once; authoring will take place thousands of times. And according to the design principles of HTML5 itself, author needs must take precedence over browser maker needs. Not to mention those other HTML5 design principles: solve real problems, pave the cowpaths, support existing content, and avoid needless complexity.
Authors should not be burdened with additional complexity. If implemented,
img set stands to introduce countless points of failure—and, at worst, something so indecipherable that authors will simply avoid it.
I’m sure no one is going to defend to the death the idea that the
audio tags are paragons of efficient markup, but they work. For better or worse: the precedents they’ve set are here to stay. Pave the cowpaths.This is how HTML5 handles rich media with conditional sources, and authors are already familiar with these markup patterns. The potential costs of deviation far outweigh the immediate benefit to implementors.
Any improvements to client-side asset delivery should apply universally. By introducing a completely disparate system to determine which assets should be delivered to the client, improvements may well have to be made twice to suit two systems: once to suit the familiar
media attribute used by
videotags, and once to suit the
img tag alone. This could leave implementors maintaining two codebases that effectively serve the same purpose, while authors learn two different methods for every advancement made. That sounds like the world before web standards, not the new, rational world standards are supposed to support.
It’s hard to imagine why there’s been such a vehement defense of the
img set markup. The
picture element provides a wider number of potential use cases, has two functional polyfills today (while an efficient polyfill may not even be possible with the ‘img set’ pattern), and has seen an unprecedented level of support from the developer community.
img set is the pattern preferred by implementors on the browser side, and while that is certainly a key factor, it doesn’t justify a deficient solution. My concern is that the unspoken argument against
picture on the WHATWG mailing list has been that it wasn’t invented there. My fear is that the consequences of that entrenched philosophy may fall to our users. It is they who will suffer when our sites fail (or when developers, unable to understand the WHATWG’s challenging syntax, simply force all users to download huge image files).
I’ll be honest: for me, no small part of this is about ensuring that we designers and developers have a voice in the standards process. The work that the developer community has put into the
picture element solution is unprecedented, and I can only hope that it marks the start of a long and mutually beneficial relationship between we authors and the standards bodies—tumultuous though that start may be.
We developers should—and can—be partners in the creation of new standards. Lend your voices to this discussion, and to others like it in the future. The web will be better for it.
If you want to avoid Google’s Penguin update (or recover from it), you’re going to have to make sure your site falls in line withGoogle’s quality guidelines. We’ve been posting various articles on these guidelines, such as:
One of Google’s guidelines is: “Avoid ‘doorway’ pages created just for search engines, or other ‘cookie cutter’ approaches such as affiliate programs with little or no original content.”
So, let’s look at exactly what Google has to say about doorway pages (from Google’s help center):
Doorway pages are typically large sets of poor-quality pages where each page is optimized for a specific keyword or phrase. In many cases, doorway pages are written to rank for a particular phrase and then funnel users to a single destination.
Whether deployed across many domains or established within one domain, doorway pages tend to frustrate users, and are in violation of our Webmaster Guidelines.
Google’s aim is to give our users the most valuable and relevant search results. Therefore, we frown on practices that are designed to manipulate search engines and deceive users by directing them to sites other than the ones they selected, and that provide content solely for the benefit of search engines. Google may take action on doorway sites and other sites making use of these deceptive practice, including removing these sites from the Google index.
Google’s Matt Cutts recently posted a video confirming that Google doesn’t consider tweets from Twitter accounts that post every article from a site to be doorway pages.
It might seem strange that someone would even ask about that:
…but, as Cutts has suggested more than once in recent memory, people shouldn’t have to be SEO experts or worry too much about SEO to still be found in Google, if the quality and relevance is there.
Also, as Google has admitted in the past, no algorithm is perfect, and when they launch a major update that impacts a lot of sites, webmasters who don’t know what they did wrong (if in fact they did do something wrong) are looking for any possible thing that Google’s imperfect algorithm might have found questionable.
They say, “There’s no such thing as a stupid question.”
If it were all so simple, Cutts wouldn’t have any reason to record endless Webmaster Help videos.
Anyhow, Google views doorway pages as those who are deceptively leading users to low quality specifically-optimized pages, and that’s what you want to avoid doing. Just don’t use pages designed to take users to places they’re not trying to go. That’s where they’ll get you.
In that particular guideline, Google says to avoid appoaches with “little or no original content.” That’s an important thing to consider, as well. Whereas Penguin is designed to target sites violating the quality guidelines, this could get you in trouble there, but it could also get you in trouble with the ever-refreshing Panda update (2 refreshes in April alone), which is focused specifically on content quality.
Google actually has a help center article specifically defining “little or no original content,” where the company says, “One of the most important steps in improving your site’s ranking in Google search results is to ensure that it contains plenty of rich information that includes relevant keywords, used appropriately, that indicate the subject matter of your content.”
“However, some webmasters attempt to improve their page’s ranking and attract visitors by creating pages with many words but little or no authentic content,” Google adds. “Google will take action against domains that try to rank more highly by just showing scraped or other auto-generated pages that don’t add any value to users. ”
Google goes on to give examples as being: thin affiliate sites (noting that being an affiliate is no problem as long as there’s added value), doorway pages, auto-generated content and scraped content.
Here’s a good piece of advice Cutts gave on his personal blog back in 2005: “Do not hire an assclown SEO that makes doorway pages with sneaky redirects.”
If someone came to you and said “I want to rent out your mail server. I’d like to send out some emails from your server, and I’ll give you $N to do it,” you’d be suspicious and probably say no–unless you wanted your mail server to end up on email blacklists. In the same way, if someone comes to you and says “I’ll give you $N to rent subdomains, subdirectories, or pages from you. Just link to my doorway pages from your content,” I would recommend to say no as well. It can affect the reputation of your domain if you host doorway pages for someone else and then that other person creates spam on the pages on your domain.
About a year and a half ago, Webmaster Tools started sending out notices about doorway pages.
Image: Batman Returns (Warner Bros.)