Jump to content
  • Addthis - IPS Plugin


    addthis.png.7b234c78862f785be85ba9dc35dba8a6.pngA free plugin that will enable you to add the addthis to your website,

    Get Addon: Click Here To Download

    • Once you have installed the plugin go to the plugin settings and set enable to on then enter your publisher id click save

    • You will need to make sure you setup addthis on their website and once you have the publisher id you are able to use this plugin.

     Bug Tracker |-| Feature Requests |-| Support Forum


  • MultiPur - IPS Theme

    multipur-blue1.thumb.png.64bd31c8a977d4259dc04084f8a73c1c.pngMulti Purpose IPS Theme that has various options and settings to make this theme very customizable, It is great for a nice clean website and projects you are looking to setup thats different from the rest with a few tweaks of the settings. The choice is totally upto you

    Get Theme: Click Here To Download

    • Our core website uses an edited master xml and on theme selector we have the outter dark red.

    • If you wish to have the Theme for Free you can Earn points by being active on our website.

     Bug Tracker |-| Feature Requests |-| Support Forum


  • Multipur 1.0.0 Theme Released

    Multi Purpose IPS Theme that has various options and settings to make this theme very customizable, It is great for a nice clean website and projects you are looking to setup thats different from the rest with a few tweaks of the settings. The choice is totally upto you
    Get Theme: Click Here To Download
    Our core website uses an edited master xml and on theme selector we have the outter dark red.
    Bug Tracker
    Feature Requests
    Support Forum
    Remove Copyright:
    Costs $35 USD if you wish to remove the copyright in the footer (Designed By: Storm Developers) 
      Click Here
      Theme Basics:
    Fully Responsive
    Included Master XMLs ( Blue ) & Outter Dark Red
    Version 1.0.0:
    Theme options of this theme has a range of features, Listed below these are the additional options that extends the core IPS standard colors and settings.
    Add Favicon
    Logo Max Height ( So fits well with your design and is not going to be too large)
    Use of a background image if you do not wish to use a standard color
    Gradient Options and angle degree if you dont want standard color or background image
    Choice to use original IPS footer or use our called “Mega Menu”
    Options to edit mega menu background, font color, link color, link hover color
    Footer Gradient Color Options and angle degree
    Use of background image
    Edit links and menu layout from the footer tab
    Enable a top border with choice of color
    Main Nav – background options also gradient, angle degree options
    Main Nav Active / Hover State – background options also gradient, angle degree options
    Sub Menu – background and font color options also gradient, angle degree options
    Enable a Drop shadow and color of choice
    modify default menu you can add margin and rounded corners
    use of custom css if you wish to change the menu that fits your needs
    Sections (forum and sitewide section headers):
    Standard background color
    Option to enable gradient color with angle degree to change the color of choice
    Option to enable a border at bottom of these headers with a choice of color
    Widgets (sidebar / other)
    Standard background color choice
    Font color of choice
    Option to enable gradient with angle degree to change the color of choice
    Option to enable a border at bottom of these headers with a choice of color
    Sections and Widgets Borders enable or disable
    Sections and Widgets Borders color of choice
    Enable site body background image if you wish to not use standard color
    Body background gradient color options with angle degree if enabled
    Enable Author Panel background (APB)
    APB – Color of choice
    APB – Gradient colors and angle degree of choice
    APB use image instead ( If you prefer to use a background image)
    Global Messages:
    Displays at top of site (sitewide) if you need to make an important announcement
    Title Background Gradient Colors and angle degree of choice
    Fully color editable on the header and content with font color of choice too.
    Border bottom on or off with the options to choose a color
    Addthis bar on website (Needs addthis registration and publisher id)
    Plus more to come as we work on it further.

    Common Concerns And Privacy In Web Forms

    Many conversations in our industry tend to circle around strong opinions and universal answers. Choosing a shiny new technical stack or sticking to an old-school paradigm; betting on a trendy framework or building a custom light framework of your own; using an attention-grabbing pop-up or sticking to calmer, less annoying solutions. We tend to have strong opinions about design and development, and so we agree and disagree, and argue endlessly, trying to protect and explain our views. Sometimes (and maybe a bit too often) to the point that conversations escalate and result in annoyingly disgruntled camps not agreeing on anything.
    It’s not the stubbornness that brings us there, though. It’s the simple fact that we all have different backgrounds, expectations, and experiences. But sometimes we end up debating answers that are all acceptable and seeking the ultimate truth in a place where it really can’t exist. This pattern shows up for the usual suspects: accessibility, performance, tooling, workflows, and naming conventions. It also repeats itself with topics that are often considered to be ephemeral: ethics and privacy.
    In the past, these topics could be spotted sporadically on the remote fringes of Twitter threads and blog posts. These days we’ve become very aware of the frightening dimensions that collection and use of personal data have gradually and silently gained. So we’ve started fighting back. Fighting back by publicly complaining about privacy-related dark patterns, unsolicited emails, shady practices, strict legal regulations, and ad-blocker wars against disruptive ads from hell. Of course, these are all important conversations to have and raising awareness is important; but we also need an applicable, pragmatic approach for designing and building ethical and respectful interfaces within our existing, well-established processes. We could use a few established patterns to bake in privacy-aware design decisions into our interfaces by default.
    As a part of Smashing consultancy and teaching at universities and schools, over the last several months I was privileged to run interviews with 62 customers of various ages and experiences in Belgium, the Netherlands, Germany, Ukraine, USA, Serbia, Bosnia-Herzegovina, Austria, and Canada. My objective was to ascertain the role privacy plays for users these days, and how the interfaces we so thoroughly craft are perceived when it comes to various touchpoints. The findings from these interviews are the foundation of this article series.
      In this four-part series, we’ll explore some of the respectful ways to approach privacy and data collection, and how to deal with notorious GDPR cookie consent prompts, intrusive push notifications, glorious permission requests, malicious third-party tracking, and offboarding experience:
    Part 1: Privacy Concerns and Privacy in Web Forms Part 2: Better GDPR Cookie Prompts Part 3: Designing Better Notifications Part 4: Privacy-Aware Design Framework Why Aren’t Privacy-Aware Interfaces a Default?
    Imagine a beautiful, authentic historical street, paved with half-broken cobble stones, tiny vintage stores, and flourishing flowers randomly placed across the pathway. Sauntering along such charming streets is a wonderful experience, full of smells and sounds of the city that aren’t easy to capture in the daily stream of mundane tasks.
    Now imagine the very same street packed with lookalike merchandise farms stacked right next to each other, plastered with promotional posters, blinking advertising, loud music, and repeating marketing messages fighting for your attention over and over and over again. Compared with the previous experience, that’s very different, and most likely much less enjoyable.
    Unfortunately, in both of the scenarios above, the more often we walk down that same street, the more we become accustomed to what’s happening, and in the end these experiences become normal — and even expected — along that path. Over time, we tend to get used to the way things appear and function, and especially when it comes to advertising, over time we’ve learned fairly well how to dismiss the marketing messages streaming endlessly and loudly our way.
    Not all marketing messages are ineffective, of course; in fact, most people are receptive to them, mostly because they are literally everywhere, often heavily personalized and hence relevant. We see them as an unnecessary evil that enables and finances our experience, be it reading an article, playing a game or watching a video. What came along with it, though, isn’t just visual noise and a substantial performance footprint of adverts, but also ever-increasing tracking, collection, and ongoing evaluation of private data.
    As a result, many of the online experiences we attend to on a daily basis feel more broken and frustrating than refreshing and inspiring. Over years of daily training on the websites we love and hate so much, we’ve got used to it — and many of us no longer notice how distracting, invasive, and disrespectful the websites have become.
    While boring pop-ups and annoying blinking ads might be easy to ignore or dismiss, sneaky push notifications, ambiguous copywriting, shady backdoors in seemingly friendly apps, and deceptive ads camouflaged as parts of the UI are nothing but a notorious, well-executed hustle. Not many website owners would willingly impose this kind of experience on their customers, and not many customers would knowingly return to a website that shared their private data for retargeting or reuse. With such experiences, trust and loyalty are at stake, and these days they are extremely rare and precious values that are hard to reacquire once they are lost.
    Pop-ups are rarely friendly and respectful, as they interrupt the experience. However, Medium goes to extremes when trying to make the interruption friendly and humble with strong, thoughtful microcopy. (Large preview)
    If we ask ourselves why honest interfaces haven’t made a breakthrough yet, bypassing and pushing away all the culprits out there, it’s not easy to find an answer at first. It’s not that designers want to manipulate customers, or that developers want to make experiences slower, or that marketeers are happy to endlessly frustrate and confuse users’ experience for the sake of one-off campaigns.
    In a world where every brand demands immediate and uninterrupted attention, attention has become incredibly scarce, and so competing against loud guerrilla campaigns with a subtle, humble marketing message might feel remarkably inferior. Clever, subtle campaigns can be effective, but they need to be constantly invented anew to remain interesting — and there is no guarantee they actually will work. On the other hand, it’s much easier to rely on solutions that worked well in the past — they are predictable, easy to measure, and not too difficult to sell to clients.
    In fact, we tend to rely on predictable A/B tests that give us clear answers for measurable, quantifiable insights. But when it comes to ethics and the long-term impact of an interface on loyalty and trust, we are out there in the blue. What we are missing is a clear, affordable strategy for meeting business requirements without resorting to questionable practices that proved to be effective in the past.
    In most conversations I’ve had with marketing teams over the years, the main backlash against all the UX-focused, customer-protective changes in marketing was the simple fact that marketing teams didn’t believe for a second that they could be as competitive as good ol’ workhorse techniques. So while, of course, calm, ethical, and privacy-aware interfaces would benefit the user, moving away from the status quo would massively hurt business and make companies less competitive.
    Sadly enough, they might be right. Most of us use well-known services and websites that have all the despicable practices we so love to hate. Tracking, and collection and manipulation of data are at the very core of their business models, which allow them to capitalize on it for advertising and selling purposes. In fact, they succeed, and for many users, trading privacy is an acceptable cost for all the wonderful benefits that all those giants provide for nothing. Beyond that, moving away from these benefits is remarkably hard, time-consuming, and just plain painful, so unless a company hurts its users on a level that goes way beyond harvesting and selling data, they are very unlikely to leave.
    'Confirmshaming', one of the dark patterns used too frequently on the web. Image source: confirmshaming.tumblr. Many dark patterns are collected by Harry Brignull on darkpatterns.org. (Large preview)
    Many of you might remember the golden days when the first mobile interfaces were clunky and weird and slow, and when everything seemed to be out of place, and we were desperately trying to fill all those magical rectangles on shiny new mobile phones with adaptive and pixel-perfect layouts.
    Despite good intentions and wondrous ideas, many of our first interfaces weren’t great — they just weren’t good executions of potentially great ideas. As time passed, these interfaces slowly disappeared, replaced by solutions that were designed better, slowly carved out of thorough efforts in research and testing, and gradual, ongoing refinements. It’s rare we see and regularly use some of those old interfaces today. Sometimes they remain locked up in app ecosystems, never updated or redesigned, but the competition pushed them away hastily. They just aren’t competitive enough, because they weren’t comfortable enough to enable users to reach their goals.
    I wonder if the same will happen with the new wave of privacy- and ethics-aware applications. Well-designed, small applications that do simple tasks very well, with a strong focus on ethical, respectful, and honest pixels, without shady backdoors and psychological tricks. We can’t expect giants to change overnight, but once these alternative solutions start succeeding, they might be forced to refine their models in response. I strongly believe that taking good care of users’ data can be a competitive advantage and a unique selling proposition that no other company in your niche has.
    For that to happen, though, we need to understand common pain points that users have, and establish interface patterns that designers and developers could easily use. We’ll start with common privacy concerns and seemingly obvious interface components: privacy-related issues often raised in web forms.
      Eliminating Privacy Concerns
    So you designed a wonderful new feature: an option to connect your customers with their friends by importing contacts from Facebook, LinkedIn, Twitter, or perhaps even their contact list. Imagine the huge impact on your sign-ups if only a fraction of your existing customers choose to use the feature, connecting with dozens and hundreds of their friends on your wonderful platform! Unfortunately, the feature is likely to have difficulties taking off, not because it isn’t designed well, but because of the massive abuse of privacy that users have been exposed to over the years.
    Remember that awkward conversation with a few friends wondering about an unusual invitation they received from you the other day? You didn’t mean to annoy your friends, of course, but the service you’ve just signed up to was happy to notify your friends on your behalf, without your explicit permission. Perhaps recommended default settings during installation contained a few too many checkboxes with ambiguous labels, or perhaps the app just wouldn’t work correctly otherwise. You didn’t think anything at the time, but you’ll definitely think twice next time, before leaving all of those checkboxes opted-in.
    In general, when asked about what kinds of privacy issues customers seem to be worried about, the following concerns have been raised, in order of magnitude or severeness:
    Tracking and evaluating user preferences, location, and so on Convoluted privacy policy changes Lack of trust for free or freemium services Disturbing and annoying advertising in apps or on websites Targeting with commercial and political messages Unwanted notifications and marketing emails No proper control of personal data Exposing personal preferences to third parties Difficulty to delete personal details Difficulty to cancel or close account Safety of stored data on servers Uploading a photo of a credit card or passport scan Use of personal data for commercial purposes Exposing private messages and emails publicly Exposing search history publicly Social profiling by potential employers An app posting on user’s behalf Difficulty to export personal data Difficulty to cancel a subscription Hidden fees and costs not explicitly mentioned Importing contact details of friends Trolling and stalking online Data breach of login, password, and credit card details Hacked Gmail, Facebook, Twitter, or Instagram accounts It’s quite astonishing to see how many concerns our humble interfaces raise, producing doubt, uncertainty, and skepticism in our customers.
    They don’t come out of nowhere, though. In fact, conversations about privacy often share a common thread: dreadful previous experiences that users had to learn from — the hard way. Usually it’s not those password input nightmares or frustrating CAPTCHAs; instead, it’s credit card fraud after an online purchase, and never-ending emails from companies trying to lure you in; and unsolicited posts, check-ins, and recommendations graciously posted on user’s behalf. So it shouldn’t be very surprising that for most customers the default behavior and response for pretty much any request of personal data is “Block,” unless the app makes a strong, comprehensible case of why the permission should be granted.
    This goes for importing contacts as much as for signing in with a social login: nobody wants to spam their friends with random invitations or have an app polluting their profile with automated check-in messages. On the other hand, anonymous data collection always wins. Whenever the word “anonymous” made its appearance in privacy policies, security updates, or web forms, customers were much less reluctant to share their personal data. They understood that the data is collected for marketing purposes, and wouldn’t be used to target them specifically, so they had no issues with it at all across the board. So if you need to gather some data, but don’t need to target every individual customer, you are likely to cause fewer concerns with your customers.
    One of the most dreadful features out there: importing contacts from other social networks. Very often, customers associate this feature with nothing but annoying and irreversible spam. (Large preview)
    In our interviews, users often spoke about “being burned in the past,” which is why they tend to be careful when granting permissions for any kind of data or activities online. Some users would have a dedicated credit card for online purchases, heavily protected with 2-factor authorization via their phone; others would have dedicated spam or throwaway email address for new accounts and registration, and yet others would never share very personal information in social networks. However, all these users were in a small minority, and most of them changed their attitude after they had experienced major privacy issues in the past.
    We have to design our interfaces to relieve or eliminate these concerns. Obviously, this goes very much against dubious practices for tricking customers into posting, sharing, engaging, and adding value to our platforms, hence exposing their personal data. This might also work against the business goals of the company that is heavily dependent on advertising and maximizing customer fees. However, there is a fine line between techniques used to keep users on the site and exploiting their privacy. We need to eliminate privacy concerns, and there are a few straightforward ways of doing so.
      Privacy In Web Forms
    While it’s been a good practice to avoid optional input fields and ask only for the information required to complete the form, in the real world web forms are often poisoned with seemingly random questions that appear absolutely irrelevant in the user’s context.
    The reason for this isn’t necessarily malicious in intent, but rather technical debt, as the site might be using a site-wide component for all forms, and it simply doesn’t allow for enough flexibility to fine-tune the forms appropriately. For example, when asking the user for their name, we’ve become accustomed to breaking a full name into first name and family name in our forms, sometimes with a middle name in between.
    From a technical perspective, it’s much easier to save structured data this way, but when asking for a person’s name in a real-life conversation we hardly ever ask specifically for their first name or last name — instead we ask for their name. In some countries, such as Indonesia, the last name is very uncommon, and in others a middle name is extremely rare. Hence, combining the input into a single “Full name” input field seems most plausible, yet in most web forms out there, it’s rarely the case.
    That means that in practice, seemingly random questions have to be asked at times, even though they aren’t really required. On the other hand, marketing teams often need personal information about their customers to be able to capture and present the reach and specifics of the audience to their potential advertisers. Gender, age, preferences, habits, purchasing behavior and everything in between falls under this category. And that’s not the kind of data that users are happy to willingly hand over without a legitimate reason.
    When running interviews with users, we’ve identified a few common privacy-related data points that were considered to be of a “too private, too intrusive” nature. Obviously, it heavily depends on the context too. Shipping address is perfectly acceptable at a checkout, but would be out of place in an account sign-up form. Gender would be inappropriate in an anonymous donation form, but would make perfect sense on a dating website.
    In general, users tend to raise concerns when asked about the following details (in order of magnitude or severeness):
    Title Gender Age Birthday Phone number Personal photo Credit card or bank details Signature Passport details Social security number Admittedly, only a few users would abandon a form just because it’s asking for their title or gender. However, if the questions are framed in an inappropriate way, or many of the questions seem to be irrelevant, all these disturbances start to add up, raising doubt and uncertainty at the point when we, as designers, want to ensure clarity and get all potential disturbances out of the way. To avoid that, we need to explain why we need a user’s data, and provide a way out should the customer want to keep the data private.
    Explain Why You Need A User’s Data
    With numerous data breaches, scam mails, and phishing websites permanently reminding users of the potential implications of data misuse, they rightfully have doubts and concerns about sharing private information online. We rarely have second thoughts when asked to add a few seemingly harmless radio buttons and input fields to a form, but the result is often not only a decrease in conversion, but a long-lasting mistrust of customers towards the brand and its products.
    As a result, you might end up with people submitting random data just to “pass through the gates,” as one interviewer called it. Some people would creatively fight back by providing random answers to “mess up the results.” When asked for a phone number, some would type in the correct number first (mostly because they expect the input to be validating the correct format of the phone number), and then modify a few digits to avoid spam calls. In fact, the more personal data a website is attempting to gather, the more likely the input is to be purposefully incorrect.
    Just-in-time explanations with the info tooltip in forms. Explaining why you need a user’s data matters. Image source: Claire Barrett. (Large preview)
    However, customers rarely have concerns when they fully understand why particular private information is required; the doubts occur when private information is required without an adequate explanation. While it might be obvious to the company why it needs particular details about its users, it might not be obvious to users at all. Instead, it might appear suspicious and confusing — mostly owing to the simple lack of understanding of why it’s actually needed and if it might be misused.
    As a rule of thumb, it’s always a good idea to explain exactly why the private data is required. For example, a phone number might be required to contact the customer in case a package can’t be delivered. Their birthday might be required to customize a special gift for a loyal customer. Passport details might be required for identity verification when setting up a new bank account.
    All these reasons have to be explicitly stated as a hint next to the input field; for instance, revealed on tap or click behind an info icon, to avoid confusion and misunderstanding. For the same reason, if you’re aware that some questions might feel weird for a particular set of customers, make them optional and indicate they can be skipped if they seem to be not applicable.
    It’s also a good idea to reassure the user that you take their privacy seriously, and that their data will be protected and, most importantly, will not be used for any targeted marketing purposes nor shared with third parties. Surprisingly, the latter seemed to be even more important to a large number of users than the former, as they didn’t want their data to “end up in random, inconvenient, places.”
    Always Provide A Way Out
    We have all been there: the reality is rarely a set of straightforward binary choices, and more often than not, it’s a spectrum of possibilities, without an obvious set of predefined options. Yet isn’t it ironic that our interfaces usually expect a single, unambiguous answer for reasonably ambiguous questions?
    When designing the options for title and gender, we tend to think in common patterns, providing a strict set of predictable options, basically deciding how a person should identify themselves. It’s not our place to do so, though. Not surprising, then, that for some users the options felt “patronizing and disrespectful.” A common area where this problem occurs frequently is the framing and wording of questions. Gender-neutral wording is less intrusive and more respectful. Instead of referring to a specific gender, you could keep the tone more general; for instance, asking for the age of a spouse rather than wife or husband.
    The world is rarely binary. Always provide a way out when specifying gender. Check the article on inclusive form design for gender diversity. Also, askingaboutgender.tumblr.com collects good UX practices for collecting and displaying information about gender. (Large preview)
    To avoid lock-in, it’s a good strategy to always provide a way out should the customer want to specify input on their own, or not want to share that data. For title and gender it might be as easy as providing an additional input field that would allow customers to specify a custom input. A checkbox with “I’d rather not say” or “I’d like to skip this question” would be a simple way out if customers prefer to avoid the question altogether.
    Always Ask For Exactly What You Need, Never More
    What question seems to be more personal to you: your age or your birthday? In conversations with users, the former was perceived much less personal than the date of birth, mostly because the former is more broad and general. In reality, although companies rarely need a specific date of birth, the required input contains masks for the day, month, and year.
    There are usually three reasons for that. On the one side, marketing teams often want to know the age of the customer to understand the demographics of the service — for them, a specific date of birth isn’t really necessary. On the other side, when a company wants to send out custom gifts to a customer on their birthday, they do need the day and the month — but not necessarily the year.
    Never ask more than you need. For its age prompt, Carlsberg used to ask only the year of birth, and ask for month and day only if necessary to verify that the customer is over 18 years old. (Large preview)
    Finally, depending on local regulations, it might be a legal requirement to verify that a website visitor is over a certain age threshold. In that case, it might be enough to ask the customer if they are over 18 rather than asking them for their date of birth, or ask them only for the year of birth first. If they are definitely younger than 18, they might not be able to access the site. If they are definitely older than 18, they can access the site. The prompts for the month should appear only if the user might be just below or just above 18 (born 18 years ago). Finally, the day input would appear only if it’s absolutely necessary to check if the user is old enough to enter the site.
    When designing an input for age or date of birth, consider the specific data points that you need and design the form accordingly. Try to minimize the amount of input required, and (again) explain why for what purpose you need that input.
    When Asking For Sensitive Details, Prepare Customers Ahead Of Time
    While users can find a way to “pass through the gates” with title, gender, age, birthday, and even phone number input, they will have a very difficult time finding a way out when asked for their photo, signature, credit card, passport details, or social security number. These details are very personal and customers tend to spend a disproportionate amount of time filling in these input fields, slowing down massively as they do so. Often this area would be where the users would spend most of their time, and also where they abandon most frequently.
    When asked to type in this kind of data, customers would often linger around the interface, scanning it from top to bottom and right to left or scrolling up and down — almost hoping to detect a reassuring confirmation that their data will be processed securely. Almost nobody would mindlessly load their personal photo or type in their passport details without a brief reassurance phase, both on mobile and on desktop.
    There are a few strategies to alleviate the concerns users might have at this point. Because users slow down significantly in their progress, always provide an option to save and finish later, as some users might not have the details to hand. You could ask for their phone number or email to send a reminder a few hours or days later. Additionally, consider reassuring users with a noticeable hint or even pop-up that you take their privacy seriously and that you would never share details with third party.
    It might also be a good idea to prepare the customer for the required input ahead of time. You could ask them to prepare their passport and bank account details before they even start filling in the form, just to set the right expectations.
    The more sensitive private details are, the less room for amusing remarks there should be. The voice and tone of accompanying copywriting matter a lot, just like the copy of error messages, which should be adaptive and concise, informing the user about a problem and how it could be fixed.
    Don’t Expect Accurate Data For Temporary Accounts
    You’ve been here before: you might be having a quick bite in a coffee shop, or waiting for your spouse in a shopping mall, or spending a few layover hours at an airport. It probably won’t take you long to discover a free Wi-Fi hotspot and connect to it. Suddenly, a gracious pop-up window makes its glorious appearance, informing you about 15 free minutes of Wi-Fi, along with a versatile repertoire of lengthy text passages, auto-playing video adverts, painfully small buttons, tiny checkboxes, and miniature legal notices. Your gaze goes straight to where it matters most: the sign-up area prompting you to sign in with Facebook, Twitter, Instagram, SMS, or email. Which option would you choose, and why?
    Throughout our interviews, we’ve noticed the same behavior over and over again: whenever customers felt that they were in a temporary place or state (that is, they didn’t feel they might be returning any time soon), they were very unlikely to provide accurate personal data. This goes for Wi-Fi in airports as much as in restaurants and shopping malls. Required sign-ups were usually associated with unsolicited marketing emails, mostly annoyingly irrelevant. After all, who’d love to receive notifications from Schiphol Airport if they’ve only flown from it once?
    Every time a temporary account requires email, expect a throwaway email to be entered. Such forms just don’t work, so it’s about time to stop designing them. More examples of such interfaces can be found here. (Large preview)
    In fact, users were most unlikely to log in with Facebook, Twitter, or Instagram, because they were worried about third-party services posting on their behalf (we’ll cover these issues in a bit more detail later in this series). Many customers just didn’t feel comfortable letting an unknown third party into what they consider to be their “private personal sphere.” Both SMS and email were perfectly acceptable, yet especially when traveling, many customers didn’t know for sure if they’d be charged for text messages or not, and referred email instead. Hence, it’s critical to never enforce a social sign-in and provide a way out with an SMS confirmation or an email sign-up.
    With the email option chosen, however, only a few people would actually provide their active personal or business emails when signing up. Some people keep a trash email, used for new accounts, quick confirmations, random newsletters and printing documents in a print shop around the corner. That email is hardly ever checked, and often full of spam, random newsletters, and irrelevant marketing emails. Chances are high that your carefully crafted messages will be enjoying the good company of these messages, usually unopened and unread.
    Other people, when prompted to type in their email, provide a random non-existent @gmail.com account, hoping that no verification will be required. If it is required after all, they usually return and provide the least important email account, often a trash email.
    What happens if the service tries to ensure the validity of the email by requiring user to retype their email one more time? A good number will try to copy-paste their input into the email verification input field, unless the website blocks copy-paste or the email input is split into two inputs, one for the segment before the @ symbol, and one after it. It shouldn’t be too surprising that not a single customer was particularly thrilled about these options.
    Users seem to highly value a very strict separation between things that matter to them and things that don’t matter to them — especially in their email inbox. Being burned with annoying marketing emails in the past, they are more cautious of letting brands into their private sphere. To get their attention, we need to give customers a good reason to sign up with an active email account; for example, to qualify for free shipping, or auto-applied discounts for loyal customers, or an immediate discount for next purchases, or a free coffee for the next visit. One way or another, we need to deserve their trust, which is not granted by default most of the time.
    Don’t Store Private Data By Default
    When setting up an account, it’s common to see interfaces asking for permission to store personal data for future use. Of course, sometimes the reason for it comes from the objective to nudge customers into easy repurchasing on future visits. Often it’s a helpful feature that allows customers to avoid retyping and save time with the next order. However, not every customer will ever have a second order, and nobody will be amused by an unexpected call from the marketing department about a brand new offering.
    Customers have no issues with storing gender and date of birth once they’ve provided it, and seem to be likely to allow phone numbers to be stored, but they are less likely to store credit card details and signature and passport details.
    Hence, it’s plausible to never store private data by default, and always ask users for permission, unchecking the checkbox by default. Also, consider storing details temporarily — for a few weeks, for example — and inform the user about this behavior as they are signing up.
    In general, the more private the required information is, the more effort should be spent to clearly explain how this information will be processed and secured. While a subtle text hint might be enough when asking for a phone number, passport details might need a larger section, highlighting why they are required along with all the efforts put into protecting user’s privacy.
    Users Watch Out For Privacy Traps
    The more your interface is trying to get silent consent from customers — be it a subscription to email, use of personal data, or pretty much anything else — the more customers seem to be focused on getting this done, their way. It might seem like a tiny mischievous checkbox (opted-in by default) might be overlooked, yet in practice customers go to extremes hitting that checkbox, sometimes as far as tapping it with a pinky finger on their mobile phones.
    With a fundamental mistrust of our interfaces, customers have become accustomed to being cautious online. So they watch out for privacy traps, and have built up their own strategies to deal with malicious and inquisitive web forms. As such, on a daily basis, they resort to temporary email providers, fake names and email addresses, invalid phone numbers, and random postal codes. In that light, being respectful and humble when asking for personal data can be a remarkably refreshing experience, which many customers don’t expect. This also goes for a pattern that has become quite a nuisance recently: the omnipresent cookie settings prompt.
    In the next article of the series, we’ll look into these notorious GDPR cookie consent prompts, and how we can design the experience around them better, and with our users’ privacy in mind.

    Plesk VPS Hosting For Better Website Outcomes

    In early discussions you have with clients about the website you’re tasked with designing, does the topic of web hosting ever come up? My guess is that it’s not something your clients give much thought to, waving it away with:
    I get why they’d think that way. For starters, they’re paying you a large sum of money to design the site. Of course, they’re going to look to other areas to offset those costs. Because server technology is rarely understood by the people who own websites, it’s easy for them to mistakenly think they can save money there.
    Here’s the problem though:
    As a website grows in authority and expands its reach, security and performance problems will arise if the hosting configuration isn’t prepared to handle it.
    In the following article, I’m going to show you why clients need the power of VPS hosting behind the websites you design for them. And why you — the administrator — need a tool like the Plesk control panel to manage it.
    The Web Designer’s Connection to Web Hosting
    In many cases, people get stuck being the go-to person for one highly specialized task at the companies they work for. This person handles the marketing. This person manages inventory. This person coordinates client meetings.
    One of the things I love about working with websites is that there are so many new things to learn about and other areas to branch out to. If you don’t want to be relegated to building website after website, day in and day out, there are ways to expand your offering and become the total end-to-end solution provider for clients.
    In my opinion, web hosting is one of the areas you should look to for expansion. Now, I’m not saying you should become a reseller of hosting or anything like that. All I mean is that it would be beneficial to understand how the technology behind a website affects the outcomes of what you’ve built.
    For example:
    An underpowered hosting plan fails to handle influxes of traffic, which leads to slower page speeds and a drop in conversion rates. Occasional downtime on the website leaves visitors wondering if it’s even worth going to the site if its availability is unreliable. There’s a high demand for the inventory sold on the site, but potential customers are too nervous to pull the trigger since security seems to be non-existent. Even if you’re not the one responsible for the server technology your client’s site sits on, you can see how this sort of thing could have a negative effect on your business. You build an amazing website that aims to do exactly what your client wanted, but the server technology is holding it back.
    Who do you think the client is going to blame in that case?
    Rather than let it get that far, I’d suggest you engage your clients early on in conversations about their web hosting. As we move on, I’m going to present you with specific arguments you should be prepared to make regarding the hosting as well as how it’s managed.
    An Introduction To VPS Hosting
    When it comes to choosing the right hosting for your clients’ websites, there’s a lot to think about:
    Who Should You Entrust Your Website To?
    There are thousands of web hosting companies to choose from. But in terms of reliability? That list could easily be narrowed down to less than a hundred.
    HostGator has been a web hosting company I’ve recommended to clients for years, especially ones who need a powerful hosting solution like Plesk VPS hosting. If your client doesn’t have a strong preference of provider, start here.
    What Type Of Web Hosting Will Serve Your Website And Audience Best?
    This is what you need to know about the different kinds of web hosting:
    Shared Hosting
    This is the cheapest form of hosting available and probably the one your clients will be most inclined to purchase.
    The hosting provider designates a section of a web server to a number of clients who will then share the resources. This means there are strict limitations set on how much bandwidth and storage a website can use, but very little you can do to control any of it — especially if another website in the shared server space hogs the resources.
    It’s this last point that’s especially problematic on shared hosting. Although your hosting plan might indicate you get X amount of memory, it’s actually a cap on how much you might have access to if no one else is using resources from the server at the same time. In reality, it’s very likely you’ll run into lack of memory errors due to this limitation quite frequently.
    Shared hosting is fine for small, personal blogs or private websites. Not for serious businesses.
    Cloud Hosting
    This is similar to shared hosting except that it’s more secure and stable.
    Rather than relegate a website to one specific segment of a web server, the site is hosted across a number of servers. That way, if one server experiences an outage or another website compromises the performance of others around it, your website can safely be hosted elsewhere.
    That said, there are still a number of limitations that come from cloud hosting. If your website is for a growing business, but you don’t expect a lot of traffic to it (say, if it were a simple portfolio), cloud hosting would be a good choice.
    Dedicated Hosting
    This is the most robust form of web hosting, which also makes it the most expensive.
    As the name indicates, your hosting company will lease you an entire server to host your website. So, think of this like shared hosting, but on steroids. As you can imagine, when you have your own server environment, it greatly reduces the risk of anyone else compromising the performance of your website.
    That said, there is a lot more work involved in managed a dedicated hosting account and the website on it. This is really only best for large enterprises, social networks, e-commerce sites and others that require this type of extreme web hosting.
    VPS Hosting
    This stands for “virtual private server”. The name alone should give you a good idea of how this differs from the other kinds of hosting already mentioned.
    In sum, a virtual private server is like a scaled-back version of dedicated hosting. Instead of having an entire server to yourself, the web hosting company carves out a dedicated portion of the server and personalizes its settings for you. Although you share the server with other VPS clients, you don’t share the resources with anyone else. You get exactly what you pay for.
    Here are some other highlights of VPS hosting:
    It’s faster and more secure than shared or cloud hosting. It’s cheaper than dedicated hosting. It’s custom-tailored to your needs, but still allows you to take more control over your server configuration. Bottom line: VPS is an overall better hosting solution for growing businesses.
    How Will You Manage Your Web Hosting Account?
    There’s one more question you have to ask yourself before you commit to a new hosting provider and plan.
    Because VPS hosting is more complex and requires a greater degree of management than a set-it-and-forget-it type of hosting like shared or cloud, you need a control panel you can rely on.
    So, let’s explore the Plesk panel and take a look at what you can do to maximize the management of your new website with it.
    An Exploration Of Plesk VPS Hosting
    This is the Plesk website:
    Large preview
    It won’t take long to realize that Plesk is not like other control panel solutions. The website will help clarify some of this for you, but I’d like to give you an inside look at the control panel so you can see for yourself.
    A Universally Friendly Control Panel
    Plesk is one of those tools you step inside of and immediately realize you made the right choice. With a very short learning curve, Plesk is a highly intuitive control panel solution that’s great for anyone:
    Plesk is a universally user-friendly platform. (Image source: Large preview)
    In all honesty, I don’t know how much time your clients will spend inside the control panel. When I’ve managed and built websites for clients in the past, just asking for login credentials to their hosting account tended to be a real chore.
    Regardless of whether they want or know what to do with a control panel, Plesk provides a user-friendly experience regardless of who the user is as well as their level of comfort with website management. I’ll show you why in this next example.
    Words cannot describe how frustrating it is to ask clients to complete simple tasks. (Source)
    Great Interface For Clients And Other End Users
    If you’ve ever tried to use cPanel to manage hosting and domain services, you know how overwhelming it can be to use.
    If you’re not familiar with it, this is typically what cPanel looks like upon first logging in:
    This is how the cPanel interface (meant for end users) looks like. (Image source: cPanel) (Large preview)
    If you plan on reselling or managing hosting for your cPanel clients, then you'll need to use a separate dashboard called WHM:
    cPanel’s user interface (Image source: cPanel) (Large preview)
    There’s a navigation and sub-navigation bar at the top, which makes management options seem simple enough.
    Then, you’re presented with individual actions you can take to manage hosting, your website or email accounts within the control panel itself. This is just too much — even for technically-minded clients who know what the heck they’re looking for.
    Now, check out the Plesk interface for power users:
    The Plesk power user home page. (Source: Plesk) (Large preview)
    This is insanely well-organized and clearly labeled. If your clients or other novice users were to step inside of Plesk, they’d instantly know where to go as well as which actions they could possibly take from the sidebar alone.
    It gets better within each of the individual modules. For instance:
    An example of the clean layout of the Plesk UI. (Source: Plesk) (Large preview)
    This is what the Tools & Settings page looks like. As you can see, it’s not bogged down by a barrage of icons for each setting. Instead, it presents options in a succinct and well-organized manner, which will greatly reduce friction that might otherwise exist in a tool of this nature.
    Great Interface For Designers And Developers
    Plesk offers an alternative “service provider” view for web developers and designers:
    A look at the Plesk service provider interface for developers. (Source: Plesk) (Large preview)
    It looks a lot like the power user view, except you can see that the sidebar is broken up into different modules. What I like about this is that it encourages developers to manage more of their business from one tool instead of a variety of business management tools.
    From within Plesk, you can:
    Add new customer accounts and manage them from one dashboard. Adding and managing customers in Plesk is easy. (Source: Plesk) (Large preview)
    Customize what they do and see in their “power user” view of Plesk. This helps keep server and website management under control. Managing customers in Plesk is easy. (Source: Plesk) (Large preview)
    Create hosting plans that you can, in turn, sell to customers as subscriptions. Managing hosting plans in Plesk is easy. (Source: Plesk) (Large preview)
    Move non-Plesk customers over to Plesk with a simple-to-use migration tool. The Plesk Migrator extension. (Source: Plesk) (Large preview)
    Customize nearly every aspect of your clients’ server configurations. Like disk space: It’s easy to configure your server with Plesk. (Source: Plesk) (Large preview)
    Manage the essentials to ensure the server runs in tip-top shape. For instance, here are some of the PHP settings for security and performance: Security and performance controls are a priority in Plesk. (Source: Plesk) (Large preview)
    Manage things like plugins, themes and more if you build websites with WordPress. Plesk users can control various WordPress settings and tools inside of the control panel. (Source: Plesk) (Large preview)
    If you’ve ever been frustrated with the management piece of your business or felt that your ability to control things was lacking, Plesk is the solution. Plus, you can use Plesk extensions to really open this tool up. Add business management features like invoicing and site-builder tools to improve your offering, streamline your workflow and make more money.
    Last but not least, you can white label it with your branding. That way, when clients step inside, they’re reminded that they have a trusted website pro like you to properly manage their server and website.
    Flexible Workflows
    Another developer-friendly feature of Plesk is its flexibility.
    One of the issues with letting clients make decisions about their web hosting and server management is that they don’t understand the amount of work that goes into it behind the scenes. They might think:
    But you and I know it’s not that simple.
    For starters, there’s your level of comfort in using the command line. For some developers, that level of comfort is low, so having a flexible solution like Plesk that removes the need for programming is great.
    That said, you can still use the CLI if you prefer. Plesk provides you with full root access, so you won’t have to worry about being restricted to the control panel’s settings to manage your VPS server either. Like I said, it’s flexible. It allows you to work as you want to work.
    Plus, it works on a number of configurations:
    Linux vs. Windows Apache vs. nginx Ruby on Rails vs. Node.js. Whatever you choose, settings are available to deeply customize and configure each so that the VPS hosting plan works exactly as you need it to.
    Wrapping Up
    It’s your hope that when you build a website for a client, it doesn’t go to waste. You design powerful website experiences so that clients can effectively leverage their web presences to drum up new business and increase conversions.
    Sadly, something like a poor choice of web hosting can compromise all of that planning and hard work on your part. Unless you’re in the habit of designing websites for very small businesses or nonprofits, Plesk VPS Hosting is the logical choice. Not only is it a great solution in terms of easing your administration and management responsibilities, but it’s also an amazing tool for building your design business.
    If you’re interested in using Plesk VPS hosting, I’d suggest you start by looking at HostGator. In addition to being one of the leading hosting companies around the world, there is a 45-day Money-Back Guarantee available which may help you encourage your clients to give it a try.

    What's your opinion about GDPR?

    GDPR sure received a lot of uproar when it became a thing. I'm not really a fan of Europe laws and I'm glad I don't live there. 
    If you don't know what GDPR is:
    Source: Wikipedia.
    I've heard how some trolls used this to hit forums, saying how they are GDPR experts and demanded stuff from forum owners. 
    Of course, I'm going to comply but to a degree.
    I wouldn't let them take advantage and listen to their demand to delete all content they have posted on a forum/website I own. If they have their real first and last name, I would of course remove that. I would tweak my terms to ban posting personal information such as phone number, address, etc. Then there are the other minor things like privacy policy, cookie notice etc. 
    So yeah, what's your opinion about GDPR and what are you doing on your website(s) regarding it? 

    What is your favorite forum software?

    This forum uses IPB. I'm guessing the owner prefers it over other forum software. 
    I personally like xenForo. I jumped ship from vBulletin ages ago back when they had version 4 available. 5 was a complete mess from the reviews/opinions I've read. I'm so happy I did not stay with them. If xenForo was never made, I might have went with IPB, phpBB or MyBB. Probably IPB... 
    So out of all the free and paid forum software available today, which is your favorite and why? Please answer as an admin and a regular forum member. 
    Thank you! 

    Welcoming Developers to Help

    We believe that open source matters and a big project our ERP is going to be, so if you are a developer and have a bit of spare time feel free to come and join us in building our stormERP system.
    We are just starting out and hopefully it will be a fantastic PHP system that everyone will love, based on the symfony framework we feel it will be a great achievement in the php world.
    Feel free to get on board and help us build a great future for the system.
    Send us a message here or come to our github link is located on our main page.
  • Managing Z-Index In A Component-Based Web Application

    If you’ve done any complex web UI development, you must have at least once furiously tried driving an element’s z-index up to thousands, only to see that it’s not helping position it on top of some other element, whose z-index is lower or even not defined at all.
    Why does that happen? And more importantly, how to avoid such issues?
    In this article, I’ll recap what z-index actually is and how you can stop guessing whether it might work in any specific case and start treating it just like any other convenient tool.
    The Hierarchy Of Stacking Contexts
    If you imagine the webpage as having three dimensions, then z-index is a property that defines the z coordinate of an element (also called its “stacking order”): the larger the value, the closer the element is to the observer. You can also think of it as a property affecting paint order, and this will in fact be more correct since the screen is a two-dimensional grid of pixels. So, the larger the z-index value, the later the element is painted on the page.
    There is, however, one major complication. The z-index value space is not flat — it’s hierarchical. An element can create a stacking context which becomes the root for z-index values of its descendants. It would be best to explain the concept of stacking contexts by using an example.
      The document body has five div descendants: div1, div2, div3, div1-1, and div2-1. They’re all absolutely positioned and overlap with each other. div1-1 is a child of div1, and div2-1 is a child of div2.
    See the Pen stacking-contexts by Pavel Pomerantsev.
    Let’s try to understand why we see what we see. There are quite elaborate rules to determine paint order, but here we only need to compare two things:
    z-index Values
    If an element has a higher z-index, it’s painted later. Source Order
    If z-index values are the same, then the later it’s in the source, the later it’s painted. So if we don’t take stacking contexts into account, the order should be as follows:
    div1 div2 div3 div1-1 div2-1 Note that div2-1 is in fact overlapped by div3. Why is that happening?
    If an element is said to create a stacking context, it creates a basis for its children’s z-index values, so they’re never compared with anything outside the stacking context when determining paint order. To put it another way, when an element creating a stacking context is painted, all its children are painted right after it and before any of its siblings.
    Going back to the example, the actual paint order of body’s descendant divs is:
    div1 div2 div3 div1-1 Notice the absence of div2-1 in the list — it’s a child of div2 which creates a stacking context (because it’s an absolutely positioned element with a z-index other than the default value of auto), so it’s painted after div2, but before div3.
    div1 doesn’t create a stacking context, because its implicit z-index value is auto, so div1-1 (its child) is painted after div2 and div3 (since its z-index, 10, is larger than that of div2 and div3).
    Don’t worry if you didn’t fully grasp this on first reading. There’s a bunch of online resources that do a great job in explaining these concepts in more detail:
    “The Stacking Context,” MDN web docs, Mozilla “What No One Told You About Z-Index,” Philip Walton Note: It’s also great to be familiar with general paint order rules (which are actually quite complex).
      The main point of this piece, however, is how to deal with z-index when your page is composed of dozens and hundreds of components, each potentially having children with z-index defined.
    One of the most popular articles on z-index proposes grouping all z-index values in one place, but comparing those values doesn’t make sense if they don’t belong to the same stacking context (which might not be easy to achieve in a large application).
    Here’s an example. Let’s say we have a page with header and main sections. The main section for some reason has to have position: relative and z-index: 1.
    See the Pen z-index-step1 by Pavel Pomerantsev.
    We’re using a component architecture here, so CSS for the root component and every child component is defined in dedicated sections. In practice, components would live in separate files, and the markup would be generated using a JavaScript library of your choice, like React, but for demonstration purposes it’s fine to have everything together.
    Now, imagine we’re tasked with creating a dropdown menu in the header. It has to be stacked on top of the main section, of course, so we’ll give it a z-index of 10:
    See the Pen z-index-step2 by Pavel Pomerantsev.
    Now, a few months later, in order to make something unrelated work better, we apply the translateZ hack to the header.
    See the Pen z-index-step3 by Pavel Pomerantsev.
    As you can see, the layout is now broken. An element with z-index: 1 sits on top of an element with z-index: 10, in the absence of any other z-index rules. The reason is that the header now creates a stacking context — it’s an element with a transform property whose value is anything other than none (see full rules) and its own z-index (0 by default) is lower than that of the main section (1).
    The solution is straightforward: give the header a z-index value of 2, and it’ll be fixed.
    See the Pen z-index-step4 by Pavel Pomerantsev.
    The question is, how are we supposed to come to this solution if we have components within components within components, each having elements with different z-indices? How can we be sure that changing z-index of the header won’t break anything else?
    The answer is a convention that eliminates the need for guesswork, and it’s the following: changing z-indices within a component should only affect that component, and nothing else. To put it differently, when dealing with z-index values in a certain CSS file, we should ideally only concern ourselves with other values in that same file.
    Achieving it is easy. We should simply make sure that the root of every component creates a stacking context. The easiest way to do it is to give it position and z-index values other than the default ones (which are static and auto, respectively).
    Here’s one of the ways to structure the application. It uses more elements than the previous one, but computation associated with extra DOM elements is cheap whereas developer’s time (a lot of which can sometimes be spent on debugging stacking issues) is definitely not.
    See the Pen z-index-step5 by Pavel Pomerantsev.
    header__container and main__container both have position: relative and z-index: 0; header__overlay now has z-index: 1 (we don’t need a large value since it’s only going to compete for stacking order with other elements within the header); root__header now has z-index: 2, whereas root__main keeps its z-index: 1, and this is what makes the two siblings stack correctly. (Note also that both have position: relative since z-index doesn’t apply to statically positioned elements.)
      If we look at the header code now, we’ll notice that we can remove the z-index property from both the container and the overlay altogether because the overlay is the only positioned element there. Likewise, the z-index is not required on the main container. This is the biggest benefit of the proposed approach: when looking at z-indices, it’s only the component itself that matters, not its context.
    See the Pen z-index-step6 by Pavel Pomerantsev.
    Such an architecture is not without its drawbacks. It makes the application more predictable at the expense of some flexibility. For example, you won’t be able to create such overlays inside both the header and the main section:
    See the Pen z-index-step7 by Pavel Pomerantsev.
    In my experience, however, this is rarely a problem. You could make the overlay in the main section go down instead of up, in order for it to not intersect with the header. Or, if you really needed it to go up, you could inject the overlay HTML at the end of the body and give it a large z-index (“large” being whatever’s larger than those of other sections at the top level). In any case, if you’re not in a competition to build the most complicated layout, you should be fine.
    To recap:
    Isolate components in terms of z-index values of elements by making the root of each component a stacking context; You don’t have to do it if no element within a component needs a z-index value other than auto; Within a component’s CSS file, maintain z-index values any way you like. It might be consecutive values, or you could give them a step of 10, or you can use variables — it all depends on your project’s conventions and the size of the component (although making components smaller is never a bad thing). Preferably, only assign z-index to sibling elements. Otherwise, you may inadvertently introduce more stacking contexts within a component, and you’re faced with the same issue again, luckily on a smaller scale; Debugging becomes easy. Find the first ancestor component of the two elements that are not stacked correctly, and change z-indices within that component as necessary. This approach will hopefully bring back some sanity to your development process.

    How To Align Things In CSS

    We have a whole selection of ways to align things in CSS today, and it isn’t always an obvious decision which to use. However, knowing what is available means that you can always try a few tactics if you come across a particular alignment problem.
    In this article, I will take a look at the different alignment methods. Instead of providing a comprehensive guide to each, I’ll explain a few of the sticking points people have and point to more complete references for the properties and values. As with much of CSS, you can go a long way by understanding the fundamental things about how the methods behave, and then need a place to go look up the finer details in terms of how you achieve the precise layout that you want.
    Aligning Text And Inline Elements
    When we have some text and other inline elements on a page, each line of content is treated as a line box. The property text-align will align that content on the page, for example, if you want your text centered, or justified. Sometimes, however, you may want to align things inside that line box against other things, for example, if you have an icon displayed alongside text, or text of different sizes.
      In the example below, I have some text with a larger inline image. I am using vertical-align: middle on the image to align the text to the middle of the image.
    See the Pen Vertical Alignment example by Rachel Andrew.
    The line-height Property And Alignment
    Remember that the line-height property will change the size of the line-box and therefore can change your alignment. The following example uses a large line-height value of 150px, and I have aligned the image to top. The image is aligned to the top of the line box and not the top of the text, remove that line-height or make it less than the size of the image and the image and text will line up at the top of the text.
    See the Pen Vertical Alignment and line-height by Rachel Andrew.
    It turns out that line-height and indeed the size of text is pretty complicated, and I’m not going to head down that rabbit hole in this article. If you are trying to precisely align inline elements and want to really understand what is going on, I recommend reading “Deep Dive CSS: Font Metrics, line-height And vertical-align.”
    When Can I Use The vertical-align Property?
    The vertical-align property is useful if you are aligning any inline element. This includes elements with display: inline-block. The content of table cells can also be aligned with the vertical-align property.
    The vertical-align property has no effect on flex or grid items, and therefore if used as part of a fallback strategy, will cease to apply the minute the parent element is turned into a grid or flex Container. For example, in the next pen, I have a set of items laid out with display: inline-block and this means that I get the ability to align the items even if the browser does not have Flexbox:
    See the Pen inline-block and vertical-align by Rachel Andrew.
    In this next pen, I have treated the inline-block as a fallback for Flex layout. The alignment properties no longer apply, and I can add align-items to align the items in Flexbox. You can tell that the Flexbox method is in play because the gap between items that you will get when using display: inline-block is gone.
    See the Pen inline-block flex fallback by Rachel Andrew.
    The fact that vertical-align works on table cells is the reason that the trick to vertically center an item using display: table-cell works.
    Now that we do have better ways to align boxes in CSS (as we will look at in the next section), we don’t need to employ the vertical-align and text-align properties in places other than the inline and text elements for which they were designed. However, they are still completely valid to use in those text and inline formats, and so remember if you are trying to align something inline, it is these properties and not the Box Alignment ones that you need to reach for.
    Box Alignment
    The Box Alignment Specification deals with how we align everything else. The specification details the following alignment properties:
    justify-content align-content justify-self align-self justify-items align-items You might already think of these properties as being part of the Flexbox Specification, or perhaps Grid. The history of the properties is that they originated as part of Flexbox, and still exist in the Level 1 specification; however, they were moved into their own specification when it became apparent that they were more generally useful. We now also use them in Grid Layout, and they are specified for other layout methods too, although current browser support means that you won’t be able to use them just yet.
    Therefore, next time someone on the Internet tells you that vertical alignment is the hardest part of CSS, you can tell them this (which even fits into a tweet):
    .container { display: flex; align-items: center; justify-content: center; } In the future, we may even be able to dispense with display: flex, once the Box Alignment properties are implemented for Block Layout. At the moment, however, making the parent of the thing you want centering a flex container is the way to get alignment horizontally and vertically.
      The Two Types Of Alignment
    When aligning flex and grid items, you have two possible things to align:
    You have the spare space in the grid or flex container (once the items or tracks have been laid out). You also have the item itself inside the grid area you placed it in, or on the cross axis inside the flex container. I showed you a set of properties above, and the alignment properties can be thought of as two groups. Those which deal with distribution of spare space, and those which align the item itself.
    Dealing With Spare Space: align-content And justify-content
    The properties which end in -content are about space distribution, so when you choose to use align-content or justify-content you are distributing available space between grid tracks or flex items. They don’t change the size of the flex or grid items themselves; they move them around because they change where the spare space goes.
    Below, I have a flex example and a grid example. Both have a container which is larger than required to display the flex items or grid tracks, so I can use align-content and justify-content to distribute that space.
    See the Pen justify-content and align-content by Rachel Andrew.
    Moving Items Around: justify-self, align-self, justify-items And align-items
    We then have align-self and justify-self as applied to individual flex or grid items; you can also use align-items and justify-items on the container to set all the properties at once. These properties deal with the actual flex or grid item, i.e. moving the content around inside the Grid Area or flex line.
    Grid Layout You get both properties as you can shift the item on the block and inline axis as we have a defined Grid Area in which it sits. Flex Layout You can only align on the cross axis as the main axis is controlled by space distribution alone. So if your items are a row, you can use align-self to shift them up and down inside the flex line, aligning them against each other. In my example below, I have a flex and a grid container, and am using align-items and align-self in Flexbox to move the items up and down against each other on the cross axis. If you use Firefox, and inspect the element using the Firefox Flexbox Inspector, you can see the size of the flex container and how the items are being moved vertically inside of that.
    Aligned flex items with the flex container highlighted in Firefox (Large preview)
    In grid, I can use all four properties to move the items around inside their grid area. Once again, the Firefox DevTools Grid Inspector will be useful when playing with alignment. With the grid lines overlaid, you can see the area inside which the content is being moved:
    Aligned grid items with the Grid highlighted in Firefox (Large preview)
    Play around with the values in the CodePen demo to see how you can shift content around in each layout method:
    See the Pen justify-self, align-self, justify-items, align-items by Rachel Andrew.
    Confused By align And justify
    One of the cited issues with people remembering the alignment properties in Grid and Flexbox, is that no one can remember whether to align or to justify. Which direction is which?
    For Grid Layout, you need to know if you are aligning in the Block or Inline Direction. The Block direction is the direction blocks lay out on your page (in your writing mode), i.e. for English that is vertically. The Inline direction is the direction in which sentences run (so for English that is left to right horizontally).
    To align things in the Block Direction, you will use the properties which start with align-. You use align-content to distribute space between grid tracks, if there is free space in the grid container, and align-items or align-self to move an item around inside the grid area it has been placed in.
    The below example has two grid layouts. One has writing-mode: horizontal-tb (which is the default for English) and the other writing-mode: vertical-rl. This is the only difference between them. You can see that the alignment properties which I have applied work in exactly the same way on the block axis in both modes.
    See the Pen Grid Block Axis Alignment by Rachel Andrew.
    To align things in the inline direction, use the properties which begin with justify-. Use justify-content to distribute space between grid tracks, and justify-items or justify-self to align items inside their grid area in the inline direction.
    Once again, I have two grid layout examples so that you can see that inline is always inline — no matter which writing mode you are using.
    See the Pen Grid Inline Alignment by Rachel Andrew.
    Flexbox is a little trickier due to the fact that we have a main axis which can be changed to row or column. So, let’s first think about that main axis. It is set with the flex-direction property. The initial (or default) value of this property is row which will lay the flex items out as a row in the writing mode currently in use — this is why when working in English, we end up with items laid out horizontally when we create a flex container. You can then change the main axis to flex-direction: column and the items will be laid out as a column which means they are laid out in the block direction for that writing mode.
    As we can do this axis switching, the most important factor in Flexbox is asking, “Which axis is my main axis?” Once you know that, then for alignment (when on your main axis) you simply use justify-content. It doesn’t matter if your main axis is row or column. You control space between the flex items with justify-content.
    See the Pen justfy-content in Flexbox by Rachel Andrew.
    On the cross axis, you can use align-items which will align the items inside the flex container or flex line in a multi-line flex container. If you have a multi-line container using flex-wrap: wrap and have space in that container, you can use align-content to distribute the space on the cross axis.
    In the example below, we are doing both with a flex container displayed as a row and a column:
    See the Pen Cross axis alignment in Flexbox by Rachel Andrew.
    When justify-content Or align-content Do Not Work
    The justify-content and align-content properties in Grid and Flexbox are about distributing extra space. So the thing to check is that you have extra space.
    Here is a Flex example: I have set flex-direction: row and I have three items. They don’t take up all of the space in the flex container, so I have spare space on the main axis, the initial value for justify-content is flex-start and so my items all line up at the start and the extra space is at the end. I am using the Firefox Flex Inspector to highlight the space.
    The spare space at the end of the container (Large preview)
    If I change flex-direction to space-between, that extra space is now distributed between the items:
    The spare space is now between the items (Large preview)
    If I now add more content to my items so they become larger and there is no longer any additional space, then justify-content does nothing — simply because there is no space to distribute.
    There is now no space to distribute (Large preview)
    A common question I’m asked is why justify-content isn’t working when flex-direction is column. This is generally because there is no space to distribute. If you take the above example and make it flex-direction: column, the items will display as a column, but there will be no additional space below the items as there is when you do flex-direction: row. This is because when you make a Flex Container with display: flex you have a block level flex container; this will take up all possible space in the inline direction. In CSS, things do not stretch in the block direction, so no extra space.
    The column is only as tall as needed to display the items (Large preview)
    Add a height to the container and — as long as that is more than is required to display the items — you have extra space and therefore justify-content will work on your column.
    Adding a height to the container means we have spare space (Large preview)
    Why Is There No justify-self In Flexbox?
    Grid Layout implements all of the properties for both axes because we always have two axes to deal with in Grid Layout. We create tracks (which may leave additional space in the grid container in either dimension,) and so we can distribute that space with align-content or justify-content. We also have Grid Areas, and the element in that area may not take up the full space of the area, so we can use align-self or justify-self to move the content around the area (or align-items, justify-items to change the alignment of all items).
    Flexbox does not have tracks in the way that Grid layout does. On the main axis, all we have to play with is the distribution of space between the items. There is no concept of a track into which a flex item is placed. So there is no area created in which to move the item around in. This is why there is no justify-self property on the main axes in Flexbox.
    Sometimes, however, you do want to be able to align one item or part of the group of items in a different way. A common pattern would be a split navigation bar with one item being separated out from the group. In that situation, the specification advises the use of auto margins.
    An auto margin will take up all of the space in the direction it is applied, which is why we can center a block (such as our main page layout) using a left and right margin of auto. With an auto margin on both sides, each margin tries to take up all the space and so pushes the block into the middle. With our row of flex items, we can add margin-left: auto to the item we want the split to happen on, and as long as there is available space in the flex container, you get a split. This plays nicely with Flexbox because as soon as there is no available space, the items behave as regular flex items do.
    See the Pen Alignment with auto margins by Rachel Andrew.
    Flexbox And Micro-Components
    One of the things I think is often overlooked is how useful Flexbox is for doing tiny layout jobs, where you might think that using vertical-align is the way to go. I often use Flexbox to get neat alignment of small patterns; for example, aligning an icon next to text, baseline aligning two things with different font sizes, or making form fields and buttons line up properly. If you are struggling to get something to line up nicely with vertical-align, then perhaps try doing the job with Flexbox. Remember that you can also create an inline flex container if you want with display: inline-flex.
    See the Pen inline-flex example by Rachel Andrew.
    There is no reason not to use Flexbox, or even Grid for tiny layout jobs. They aren’t just for big chunks of layout. Try the different things available to you, and see what works best.
    People are often very keen to know what the right or wrong way to do things is. In reality, there often is no right or wrong; a small difference in your pattern might mean the difference between Flexbox working best, where otherwise you would use vertical-align.
    Wrapping Up
    To wrap up, I have a quick summary of the basics of alignment. If you remember these few rules, you should be able to align most things with CSS:
    Are you aligning text or an inline element? If so, you need to use text-align, vertical-align, and line-height. Do you have an item or items you want to align in the center of the page or container? If so, make the container a flex container then set align-items: center and justify-content: center. For Grid Layouts, the properties that start with align- work in the Block direction; those which start with justify- work in the inline direction. For Flex Layouts, the properties that start with align- work on the Cross Axis; those which start with justify- work on the main axis. The justify-content and align-content properties distribute extra space. If you have no extra space in your flex or grid container, they will do nothing. If you think you need justify-self in Flexbox, then using an auto margin will probably give you the pattern you are after. You can use Grid and Flexbox along with the alignment properties for tiny layout jobs as well as main components — experiment! For more information about alignment, see these resources:
    CSS Box Alignment (MDN web docs) Everything You Need To Know About Alignment In Flexbox Box Alignment Cheatsheet

    Scrimba Site for Developers

    I just found this site and I thought it might be useful for developers anyone interested in developing an App I am learning to make a chatapp from it.
    They Have GitHub Page as well
  • Latest Files

  • Our picks

    • What do you think about control panels?
      What do you think about control panels? Do you prefer to use them instead of using the command line? 
      I think they're just a waste of resources but I think people who can't handle managing their own server should buy hosting with it included or hire a sysAdmin to handle it for them, especially if the websites hosted on that server are business/commercial websites. 
      So what do you think about control panels? 
      • 4 replies
    • Is bad publicity still 'good' publicity?
      It's an age old question in the marketing realm, is even getting bad publicity about your website still publicity that you'd want as long it brings people towards your site? For me, controversy does sell, of course it depends on the scale of things but if I hear something is going down you better know that I am heading over to that place to see for myself. Of course, across the internet, rumours can just spread at the click of a button and with fake news being all the more prevalent, I think it is quite prudent of us to head to places ourselves and form our own opinion on things.

      What do you think?
      • 1 reply
    • Is Windows 10 really as horrible as they say?
      I've heard a lot and I mean A LOT of negative talk about Windows 10. 
      Of course, this was way back when Microsoft first released the operating system. I think they also made it free for a limited time if people upgraded to it. I remember some comments saying it was a trap and that you'd have to pay or something but I can't remember the details. 
      Going back on topic, is Windows 10 really as horrible as people try to make it out to be? Was it bad when it launched and has improved as of today? 
      • 5 replies
    • Remotely Hosted Forums
      There are a number of remotely hosted forum services out there; for those of you who use them, which service do you generally use?
      Even though they don't normally offer downloads of the database (downloadable databases are part of the paid brand free version), I prefer to use ProBoards. They come prepacked with most of the things that I like preboxed into a new forum anyways, like anti-spam abilities, abilities to track pageviews and other things.
      • 0 replies
    • Addons you use on forum startup
      What addons do you use on the creation of a phpBB forum? Could be your basic addons, or things you use by default, regardless of style and forum genre.
      For the forums I host using phpBB, I use the following:
      Simple Mentions - https://www.phpbb.com/customise/db/extension/simple_mentions/ User Recent Activity - https://www.phpbb.com/customise/db/extension/user_recent_activity/ Stop Forum Spam - https://www.phpbb.com/customise/db/extension/phpbb_3.1_stop_forum_spam/ Post Count Requirements - https://www.phpbb.com/customise/db/extension/post_count_requirements/ Application Form - https://www.phpbb.com/customise/db/extension/application_form/ Advanced BBCode Box 3 - https://www.phpbb.com/customise/db/extension/advanced_bbcode_box/ phpBB Media Embed Plugin - https://www.phpbb.com/customise/db/extension/mediaembed/ Topic Preview - https://www.phpbb.com/customise/db/extension/topicpreview/ Advertisement Management - https://www.phpbb.com/customise/db/extension/ads/ Auto Groups - https://www.phpbb.com/customise/db/extension/auto_groups/ Akismet Anti-Spam - https://www.phpbb.com/customise/db/extension/akismet/ Post Numbers - https://www.phpbb.com/customise/db/extension/post_numbers/ Paypal Donation - https://www.phpbb.com/customise/db/extension/paypal_donation_extension/
        • Like
      • 0 replies
    • Bringing out the BanHammer
      I'm sure we're all the quickest shot in the West when it comes to throwing down the hammer at those annoying robotic spammers trying to peddle whatever pill is the latest fad, how are you when it comes to your actual members and those within your community?
      I feel it is important to take it on a case-by-case basis as each circumstance can be different and produce different outcomes. I may have a member who was always in good stead but is simply just having a bad day and lashing out at other members and causing some issues. Do I ban them straight away in this instance or do I talk to them, give them a warning and send them on their way? It can all depend in my eyes.
      What about you? How itchy is your ban hammer?
      • 5 replies
    • Become a partner of Ingramer Instagram promotion bot!
      Become a partner of Ingramer Instagram promotion bot!
      Ingramer Offers The Affiliate Program with a 30% fee!
      Business Terms and Conditions
      30% fee;
      $50 minimum of cash withdrawal;
      payment hold: 15 days;
      payment method: Paypal;
      average purchase amount of 1 person per month: $34;
      payoff period: for life (as long as we get payments of your referrals).
      Let’s calculate together!
      The Partner gets 30% of every payment, that was made by the client, who has registered via the affiliate link. A simple example: the most popular module costs $34. If you attract 100 new users, you will get $1020 per month!
      You can use the online calculator to estimate your future passive income.
      Please welcome Ingramer Affiliate Program!
      Ingramer Affiliate Program is an agreement between Ingramer service and the Partner.
      The main principle for earning money is the following:
      The Partner gets the affiliate link and an access to affiliate account from a support team via hello@ingramer.com; more info https://ingramer.com/affiliate/
      The Partner pastes the link to the blog, website, Instagram account or any other place, that will attract the Referral;
      If the Referral registers Ingramer account via the affiliate link of the Partner - the Partner gets 30% deduction from each payment
      How does it work?
      Are you ready to take a look at the real example?
      Take a look at the real personal affiliate dashboard:
      Clicks is a number of leads, that followed your affiliate link;
      Registrations is a number of people, who have registered on Ingramer;
      Accounts is a number of Instagram accounts, that has been added to the system;
      Memberships is a number of accounts, that have paid for trial or any other period of Ingramer use;
      Charges is a number of payments, that has been made to Ingramer;
      Revenue is your profit, your earnings, and your money!
      What makes Ingramer different from others?
      The most exact targeting on the market, that is based on AI-technology
      Ingramer enables targeting by hashtags that your TA uses, by the location which it points and the list of usernames that you make (that can be your competitors, for instance). Moreover, you have a possibility to add certain hashtags, locations, and usernames to the blacklist so that Ingramer not to target its actions toward such accs.
      Ingramer has advanced filters for more precise targeting. These are the language filter, the gender filter, the timezone filter.
      Best performance results
      Unlike competitors, Ingramer is a product of constant development. An average Instagram Bot performs 1000-1300 actions per day, according your setup settings.
      User-friendly Interface
      It’s really a pleasure to work with the easy-to-use tool. Just take a look at the Ingramer and appreciate the work of our team of designers. We try to make the best service for every user!

      • 0 replies
    • I have worked with symfony for a long while now and love this framework to get kick started with my projects, though i know some developers think it might be a bit of a steep learning curve, myself i get on well with it and still yes learning some of the framework i have not touched on yet but overall developments and creations are a breeze and very stable. compared to other frameworks i feel so comfortable in this one.
      What are your thoughts on symfony and what do you love or dislike about it.
      • 1 reply
    • Anyone done or consider a hosting biz?
      I'd rather avoid it - as two of my attempts were flops!   Anyway, a better option for me is "a hosting marketplace".  That's do-able.  All it takes is a lot of verifiable real traffic.
      • 2 replies
    • What's your opinion about GDPR?
      GDPR sure received a lot of uproar when it became a thing. I'm not really a fan of Europe laws and I'm glad I don't live there. 
      If you don't know what GDPR is:
      Source: Wikipedia.
      I've heard how some trolls used this to hit forums, saying how they are GDPR experts and demanded stuff from forum owners. 
      Of course, I'm going to comply but to a degree.
      I wouldn't let them take advantage and listen to their demand to delete all content they have posted on a forum/website I own. If they have their real first and last name, I would of course remove that. I would tweak my terms to ban posting personal information such as phone number, address, etc. Then there are the other minor things like privacy policy, cookie notice etc. 
      So yeah, what's your opinion about GDPR and what are you doing on your website(s) regarding it? 
      • 5 replies
  • Create New...