Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 8 of 8
  1. #1
    New to the CF scene
    Join Date
    Mar 2019
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Please Review Our Website

    Hi Friends

    We've recently launched a new version of our website (https://www.bluent.net). Kindly have a look and provide us your feedback regarding website design (look and feel), site navigation, content etc. Your feedback will be greatly appreciated and it will help really us to improve our users' experience.


    Best
    Meenu
    Last edited by vinyl-junkie; Mar 20th, 2019 at 02:44 PM. Reason: removed hyperlink

  2. #2
    New to the CF scene
    Join Date
    Mar 2019
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Looking forward to the feedback on my website especially Content of the website. It would be great if you can help.

  3. #3
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,505
    Thanks
    4
    Thanked 503 Times in 491 Posts
    **WARNING** I'm not going to sugar coat this. I don't rap, I don't jive, I just tell you how it is.

    The lack of side padding in some sections (like the "Mobile application development" header) looks more like a rendering error than intentional design. The use of massive oversized images too big to have any business in a web design certainly aren't winning any points in the agonizing load times or from a usability/navigability standpoint.

    The willy-nilly inconsistent changes in font size make the content hard to follow, in particular that flow content seems to pick sizes almost at random whilst other sections like the footer are below accessibility minimums could be considered a severe problem. In particular the use of a video in the header is an epic /FAIL/ at web development and pretty much needs to be axed ASAP.

    Many places have hard to read color contrasts such as the white text on the middling grey in the "case studies" area or the use of orange on white across the entire page. There are rules for colour contrast in the WCAG, you should likely research that or use tools like this one:

    https://webaim.org/resources/contrastchecker/

    To make sure you're not telling large swaths of users to sod off by making much of your text effectively invisible.

    It is painfully over-reliant on JavaScript for things (like the customer bar) that adds little to nothing of value to the page whilst again slowing the page load. That when running a script blocker or control extension the page falls apart miserably is a major concern.

    The use of 1.44 megabytes in 64 files is painful, hence the slow pageload since in file-counts alone we're talking 12.5 seconds of handshaking "real world" average when cache-empty, and as much as a minute worst-case regardless of the client's connection speed. That 750k of that in 7 files is JavaScript on a site that doesn't seem to do anything of value with it (unless my scripting safety blocks like ghostery are preventing them from running) and an utterly nuts 310k in 5 files of CSS on a site that even with the design woes doesn't warrant more than 32k of CSS in one file for the entire site speaks to deep underlying issues with how it was built.

    Very much what I come to expect when I see train wreck laundry lists of how NOT to write JavaScript like jQuery.

    A situation only further proven by the broken non-mouse navigation due to the gibberish use of numbered headings. That means the page is poorly to ineptly coded under the hood flipping the bird at users with accessibility needs in the process.

    Peeking under the hood to look at the code, the first thing that stands out is the use of 60k of minified HTML to deliver not even 5k of HTML and two dozen content images/media -- not even 12k of HTML's job. Before I even look at what the code says it's around five to six times the code needed to do the job WITHOUT minification!

    Which actually reading the code spells out why. Static scripting in the markup, static style in the markup, little to nothing remotely resembling logical document structure or correct semantics, endless pointless DIV, SPAN, and classes for nothing, pointlessly redundant TITLE attributes, tables for layout, and a host of other "this is not how HTML is supposed to be written" that would make me tell any paying client who brought that to me to pitch the entire mess in the trash and start over.

    Otherwise you're just chewing bandwidth for instant-bounce, little to no conversions, and again telling users with accessibility needs where to stick it.

    Apologies if that comes across as harsh, but that's the truth. Drag it 'round back o' the woodshed with a .30-06, nuzzle the barrel to its ear, and put it down like Old Yeller.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  4. #4
    New to the CF scene
    Join Date
    Mar 2019
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi DeathShadow,

    Thank you so much for providing straightforward feedback. Really appreciated! We'll definitely fix all the issues that you mentioned in the feedback.
    Can you please help us in providing feedback on the quality of the content also? We've tried to write the user-centric copy, tried to solve the pain points of the customers. However, your feedback on that area would help us to improve our wesite content as well.

    Best
    Meenu

  5. #5
    Administrator VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    11,314
    Thanks
    7
    Thanked 1,361 Times in 1,330 Posts
    Call me old fashioned but for me, for a website to be considered well coded and thought out (and truely accessible), it has to work at least in a basic fashion without JavaScript. To be fair, your site kind of works without JS, but it does look “broken”. And some sections, like the accordion on the contact page definitely don’t work.

    And for a company that promotes responsive web design your website is surprisingly unresponsive. At a viewport width between about 770 and 970 pixels the main navigation disappears completely. And between 1000 and 1100 pixels some elements (like the platform logos on https://www.bluent.net/development/o...ce-development) look squished and forgotten. And also, as a side note: the Twitter icon (stylized “t”) is just wrong and against all of Twitters brand guidelines. Looks like your site is stuck in the Web 2.0 phase of the early 2000’s.

    There are a few more things design-wise I could criticize but I don’t have the time right now. And as to the copy, I can’t say what pain points of potential customers really are that could be solved with which kind of user-centric copy. I guess you’d have to do some research within your past customers as to what convinced them to hire you (or ask people that didn’t hire you as to why they didn’t).

  6. #6
    New to the CF scene
    Join Date
    Mar 2019
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi VIPStephan

    Thank you so much for your feedback. Appreciated!
    We'll definitely look into the points you mentioned in your feedback and will try to fix them at earliest. As far as website browser resolution (width 770 and 970 /1000 and 1100 pixels) is concerned, we have ignored these assuming people may not be liking to view website on these set of browser resolutions and we focussed only on latest ones. Never mind, we'll take care of this as well. Is there any link wherein we could see the test the website resolution?

    Best
    Meenu

  7. #7
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,505
    Thanks
    4
    Thanked 503 Times in 491 Posts
    I think this response is gonna get broken into a number of lists.

    Quote Originally Posted by meenubluent View Post
    As far as website browser resolution (width 770 and 970 /1000 and 1100 pixels) is concerned, we have ignored these assuming people may not be liking to view website on these set of browser resolutions
    This is the Internet, the only thing you can know for certain about your site is that you will have no clue who will visit your site or at what resolution. That's why "Fixed width design" is a steaming pile of /FAIL/ and even just thinking about specific widths in your design is an equal failure to understand web design.

    A good site design should be:

    1) Elastic. This means designing in EM so that the entire site scales to the user's default font-size preference, that way they aren't diving for the zoom. Fonts, paddings, margins, and any widths or width triggers should be in EM. Not PX, not PT, not even percent (except perhaps font-size since there 100% == 1EM)

    2) Semi-fluid. Automatically contracting to the available screen space, and automatically expanding to whatever is free up to a limit (max-width) that prevents long lines of content from being hard to follow. (I also like to use taller line-heights to help with that last part). This way 90%+ of the work for supporting ALL sizes is already in place, and when the issues do arise as the layout gets smaller we have the final point.

    3) Responsive. Using media queries to adjust the layout so as to best fit the available screen space.

    The "ideal" design process I advocate breaks down as follows:

    1) Start with the DESKTOP layout for legacy browsers. A LOT of people claim to start with mobile first, but I find that to be utterly back-assward. Any small screen / mobile devices we care about can be customized with media queries. You know what CAN'T be customized with media queries? Legacy desktops. you create what can't be specifically targeted first, then use the media targets to cutsomize it as needed.

    2) Narrow the window until it breaks. Figure out how many EM at which it broke and apply a media query to adjust it (strip off columns, reduce paddings, etc) until it's usable again.

    3) if you are still wider than around 256 pixels, see step 2.

    ... and voila, full support for most any concievable resolution below your semi-fluid max-width value.

    It is part of the entire progressive enhancement process where you start out with the bare minimum required for meeting accessibility needs (semantic markup of content of value), and then slowly layer your fancy stuff on top of it. That way when/if the fancy stuff fails, is inapplicable to the user or device, etc, etc, it can "gracefully degrade" in a manner that still gives the end user a useful result.

    Quote Originally Posted by meenubluent View Post
    Can you please help us in providing feedback on the quality of the content also?
    It was hard enough to navigate and/or dissect to even recognize what was content and what was fluff. I'm uncertain if the page had too much content, or the massively oversized text, willy-nilly changing of font-size, images getting in the way, etc, etc, were all combining to make it hard to see if there was any logical document structure or natural organization to it.

    Basically the content just kind of felt unrelated and just slapped into the page, but it's hard to say if that's the fault of the content, or the layout... Going back to it now, I think the layout is more to blame.

    Again, progressive enhancement site building could help with that. The full process being:

    1) Start out with your content or a reasonable facsimile of future content in a flat text editor as if HTML doesn't even exist. Organize it in a manner that makes sense as this is for all intents and purposes what people on screen readers (software that reads the page aloud), braille readers, and search engines put the most emphasis on.

    2) Mark up the content semantically, saying what things are and NOT what you want them to look like!. Appearance isn't HTML's job and 99%+ of the time you choose a tag, class, or ID based on appearance, you're doing it all wrong. That's why garbage that frameworks -- such as bootcrap or w3.css -- such as class="col-12-s text-shadow box-shadow bgLight" is mentally enfeebled gibberish dragging devleopment practices back to the worst of 1997. It means using <P> for actual paragraphs, using H1..H6 and HR to establish your logical document structure of sections and subsections with the first H2 or HR being the start of your primary content. (hence HTML 5's SECTION, ARTICLE, MAIN, and ASIDE being pointless redundancies I tell people to avoid using!. These tags do not mean "Draw a line across the screen" or "I want a double break after this" and certainly not "Fonts in different weights and sizes".

    It means TABLE is for tabular data with rows, columns, and headingst that have semantic organizational relationships, and not "hurr durz, eye wuntz columms". It means OL/UL/LI for short bullet points or selections, and that's grammatical bullet points not "Ermagahd aherpaderp I want a dot before it".

    Again, if you choose any of your semantic tags (basically everything but DIV and SPAN) based on what you want things to look like, you're doing it all wrong!

    To that end, the semantically neutral tags of SPAN and DIV have no place in the markup at this time. You don't use those until:

    3) Make your first (of many) layouts. See the previous list, that goes here. This is when DIV and SPAN should be applied as hooks for styling... but WITHOUT saying what that style IS. Use classes and ID's to group the inner semantic tags for style so as to need less classes, or to say WHY something is getting a style, and not what that style is.

    4) See step 2 of the design process list.

    5) Then and ONLY then enhance the already useful and working page with JavaScript If needed. NO core / base functionality (delivery of content) should require JavaScript. JS should be viewed as a way to enhance the user experience without ever supplanting your non-scripting fallbacks.

    That's how you get to a well built high accessibility design... and if some PSD jockey tells you they're a "web designer"? Well, they're mostly full of it and unqualified to design but two things right now.

    To give you an idea what I mean, let's take your site's HTML from the opening of the BODY tag until the end of the menu. That's a massively ridiculous 15k of code. It's so massive I'm not even going to paste it here. There is NO reason for the actual code for that to be significantly more than:

    Code:
    <body>
    
    	<h1>
    		<a href="/">
    			Blue<span>Ent</span><sup>&reg;</sup><br>
    			<small>Maximum Value. <span>Achieved.<sup>&trade;</sup></span></small>
    		</a>
    	</h1>
    
    	<dl class="phone">
    		<dt>NYC</dt>
    		<dd><a href="tel:+19177935932">(917) 793 5932</a></dd>
    		<dt>HOU</dt>
    		<dd><a href="tel:+18324768459">(832) 476 8459</a></dd>
    		<dt>DFW</dt>
    		<dd><a href="tel:+12144491133">(214) 449 1133</a></dd>
    		<dt>SFO:</dt>
    		<dd><a href="tel:+14153001233">(415) 300 1233</a></dd>
    	</dl>
    
    	<div id="mail">
    		<a href="mailto:[email protected]">[email protected]</a>
    		<div>
    			Career: <a href="mailto:[email protected]">[email protected]</a>
    		</div>
    	</div>
    
    	<input type="checkbox" id="toggle_mainMenu" hidden>
    	<label for="toggle_mainMenu"></label>
    
    	<ul id="mainMenu">
    		<li>
    			<a href="/">Home</a>
    		</li><li>
    			<input type="checkbox" id="toggle_submnenu_company" hidden>
    			<label for="toggle_submenu_company">Company</label>
    			<ul>
    				<li><a href="/company">Summary</a></li>
    				<li><a href="/company/executive-summary">Guide</a></li>
    				<li><a href="/company/about-us">About Us</a></li>
    				<li><a href="/company/why-us">Why Us?</a></li>
    				<li><a href="/company/vision">Vision</a></li>
    				<li><a href="/company/journey">Journey</a></li>
    				<li><a href="/company/global-presence">Global Presence</a></li>
    				<li><a href="/company/industries-served">Industries Served </a></li>
    			</ul>
    		</li><li>
    			<input type="checkbox" id="toggle_submenu_services" hidden>
    			<label for="toggle_submenu_services">Services</label>
    			<ul class="mega">
    				<li>
    					<a href="/development">Development</a>
    					<ul>
    						<li><a href="/apps">Apps</a></li>
    						<li><a href="/development/product-development">Products</a></li>
    						<li><a href="/platforms">Platforms</a></li>
    						<li><a href="/development/portal-development">Portals</a></li>
    						<li><a href="/development/website-development">Websites</a></li>
    					</ul>
    				</li><li>
    					<a href="/support">Support</a>
    					<ul>
    						<li><a href="/support/application-maintenance">Maintenance</a></li>
    						<li><a href="/support/app-implementation">Implementation</a></li>
    						<li><a href="/support/enterprise-software-application-integration">Integration</a></li>
    						<li><a href="/support/application-migration">Migration</a></li>
    						<li"><a href="/support/testing">Testing</a></li>
    					</ul>
    				</li><li>
    					<a href="/digital-media">Digital</a>
    					<ul>
    						<li><a href="/digital-media/digital-marketing">Marketing</a></li>
    						<li><a href="/digital-media/data-insights">Insights</a></li>
    						<li><a href="/design/website-design">Design</a></li>
    					</ul>
    				</li><li>
    					<a href="/enterprise/enterprise-software-solutions">Enterprise</a>
    					<ul>
    						<li><a href="/enterprise/cloud-application-development">Cloud</a></li>
    						<li><a href="/enterprise/big-data-management-strategy">Big Data</a></li>
    						<li><a href="/enterprise/big-data-analytics-insight">Analytics</a></li>
    						<li><a href="/enterprise/mobility">Mobility</a></li>
    						<li><a href="/consulting/technology-software-consulting">Consulting</a></li>
    					</ul>
    				</li>
    			</ul>
    		</li><li>
    			<a href="/solutions">Solutions</a>
    		</li><li>
    			<a href="/press-release">Media</a>
    		</li><li>
    			<input type="checkbox" id="toggle_submenu_clients" hidden>
    			<label for="toggle_submenu_clients">Clients</label>
    			<ul>
    				<li><a href="/clients/portfolio">Portfolio</a></li>
    				<li><a href="/clients/testimonials">Testimonials</a></li>
    				<li><a href="/clients/case-studies">Case Studies</a></li>
    			</ul>
    		</li><li>
    			<a href="/blog">Blog</a>
    		</li><li>
    			<a href="/contact-us" class="contact">Contact Us</a></li>
    		</li>
    	<!-- #mainMenu --></ul>
    Stripping out the goofy JavaScripted hovers in the process and letting CSS do all the heavy lifting, comes to 3.8k, a quarter the code. If the oddball hover effects were re-implemented under "services" that too has ZERO business using JavaScript and could likely be implemented with just HTML and CSS for around another 3k of markup. Meaning that a 1:1 analogue has no real excuse for more than 7k of markup, HALF what you were using.

    Side note, those input/label are there to leverage the :checked attribute in CSS to implement small screen / toggle states for those menu items.

    It's a great spot to show exactly the problems I outlines with the DIV for nothing, data- attributes for nothing, even multiple pointless redundant title="" attributes doing nothing more than creating code bloat. In particular the JavaScript with the markup encoded inside the data- attributes there was just making you work harder, not smarter... and possibly opening up security holes since JS shouldn't be passing around markup as that indicates the use of the outdated/outmoded/disastrous innerHTML attribute.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  8. #8
    New to the CF scene
    Join Date
    Mar 2019
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hey Deathshadow,

    "This is the Internet, the only thing you can know for certain about your site is that you will have no clue who will visit your site or at what resolution. That's why "Fixed width design" is a steaming pile of /FAIL/ and even just thinking about specific widths in your design is an equal failure to understand web design."

    Thanks again for providing such wonderful feedback. I completely agree with you regarding the website resolution stuff and will surely take care of it soon.

    Honestly speaking, your feedback is going to help us a lot.

    Best
    Meenu


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •