I have created a webpage, but my boss came back saying that the page is too busy. I was just wanting some ideas of how to split up the page e.g. Accordian, tabs etc. What tactics have you implemented to break up a page into different sections?
You already named 2 of the most popular ones: accordions and tabs. The other one you're missing is "rotators".
Here's an example of one: http://www.zurb.com/playground/jquery_image_slider_plugin (also happens to be a good jQuery plugin).
Keep in mind that you can also reduce clutter by using more vertical space and embracing scrolling. Not everything has to be above the fold.
Related
I am new to coding and wanted to get some hands on practice with a project I have in mind. Here it is:
Let's say you have blank page and on the side of a screen you have several items you can choose to draw on the blank page. For example the background can be mountains, the ocean, a forest etc. On top of that you can place a house, a church or another selectable element. Whatever you like.
It is like a picture editor where you can put together a picture with different pre-given elements. Or like in video games where you can create your own character.
What would I need to build a web application for that kind of thing?
This link should get you started but it won't be the complete answer to your question - http://www.webdesignerdepot.com/2013/08/how-to-use-html5s-drag-and-drop/
Essentially, you can achieve your image dragging and dropping using similar techniques. It will require a bit of Spike work from yourself, and looking into how HTML5 can handle drag and drop. I discovered this resource fairly quickly and I think the solution you want isn't as complicated as you may think, it just requires a bit of know-how regarding drag and drop operations within HTML5 :-)
Also, there may already be some JavaScript based API's that do this sort of thing easier but I'm not too aware - I suppose starting this way could be a great introduction for you and you may wish to expand once you've done some work for it :-)
Hope this helps you and your coding journey!
I'm doing a comparison of a bunch of landing pages in the wild. I'm trying to pull out the main header and the call to action, but of course the HTML formatting of the pages varies wildly.
I started looking for H1, H2, etc. assuming that the header tags correspond to primacy, but this is often not the case. Rendered font-size* might be a better indicator, however this seems messy and wouldn't handle cases where images with alt tags are used.
What's a good strategy to identify the main heading of 100 wild landing pages using Nokogiri?
*Also- is there a clever selector for rendered font-size?
You can't do it unless you have an AI running that can determine the most semantically important section of a document.
You can't count on the tags, such as headers or meta-tags, because those can be missing entirely.
You can't count on location in the source because CSS can move things anywhere.
And, even if you think you've got it nailed by looking at the CSS, the JavaScript can rip that reality from you because it can override everything, relying on the fact it takes a human's eyes and brain to make sense of the final rendered page.
So, basically, you're going to be mostly shooting in the dark unless you have code that can understand the content of the page and determine how often a word occurs, along with its synonyms and their root words, and then determine their placement on the page after CSS and JavaScript have been run.
It's really a tough task that a lot of big companies are spending a lot of money on.
I've been thinking about this problem for a while, and not quite sure the best way to go about it.
In a rails app I have books, which have many chapters, which have many sections. Chapters are basically just containers for sections, though may contain strings of text themselves. The sections hold most of the book text.
I'm planning to build an HTML 5 ebook reader that works in a mobile browser, and I don't want the user to have to scroll down -- I want the text to break at the end of the page.
I'd assumed using split might be the way to go, but I'm not sure there's a way to break at regular intervals? Would a javascript option work better here?
I'd looked at this: Dividing text article to smaller parts with paging in Ruby on Rails but can't feasibly insert manual break marks in the text, some of which are 90,000+ words.
Any ideas would be appreciated.
I think the main problem here is that the page length will depend on the device (and possibly the text size, if that is feature of your app). You should probably send large chunks that are sure to be at least say 5 pages long, at a time and then let the javascript do the paging. Rails has no access, nor should it, to the size of the display.
Text requires very little data, you shouldn't worry about transmitting more than you need or keeping too much in memory.
You may use blank line("\n" or "") as the separator.
I'd send enough of the page content down to easily fill a page and more, then use javascript on the client slide to remove sentences from the page until the scroll-bar disappears.
Resize.js is something similar I wrote a while ago. I wanted to enlarge/reduce the font size used on a screen until the screen was just full (for a dashboard monitor).. Yours would be similar, but instead of changing the font size, you are trimming off sentences.
Let me know if you can't see how to adapt this code.
Note: I would also make the javascript note the amount of text it ends up displaying, and pass that to the server in the 'next page' request, so the server knows where to start the next page from.
The IE9 layout engine has issues with tables. Whitespace seems at the root of it.
If you've seen the infamous ghost cell you know what I'm talking about, if you haven't, consider yourself lucky and don't worry about it.
Anyways, I'd really like an HTML only sample to test "fixes" on.
I know I've seen it before in odd circumstances several layout tables deep, but I can no longer get the ghost cell to come up when I need it to.
What I need is a consistent ghost cell without invoking JS.
I've found several JS related ones, and there are plenty discussion on those when it comes to sorting.
This is a great sample:
http://www.ncf.ca/ncf/support/ie9_issue/index.html
Some discussions:
http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/28d78780-c95c-4c35-9695-237ebb912d90
http://datatables.net/forums/discussion/5481/bug-ghost-columns-when-generating-large-tables/p1
http://datatables.net/forums/discussion/8248/datatable-in-ie-9-bug-with-large-tables/p1
I managed to clean up the html quite well and still keep the issue. I replaced all the javascript with equivalent spaces & newlines, and could remove most of the elements attributes without affecting the ghost-cell.
It seems like IE has a buffer problem since removing single spaces or newlines in a "safe area" cause the ghost cell to disappear, while removing entire attributes does not affect the rendering.
I see that you have unclosed tags, but I also managed to remove them altogether (replacing with spaces) without removing the ghost cell.
Result being I have a javascript-free html with ghost-cell. See result here: http://compscicon.no/ghostcell.htm
I'm going to be going to be meeting with a number of programmers and custom software companies to get bids on creating a website for a company that I'm involved with. My question is this: What should I prepare for the programmers so that they can give me an accurate bid, timetable, etc. for the development of the website? I have a clear picture of how I would like the site to work and the features that I would like to have included.
I'd suggest using something like balsamiq to put some simple sketches together as suggested elsewhere.
Quite often the act of putting your requirements down on paper in a way that represents the actual site will flush out all manner of issues you hadn't considered before, and will give you a much clearer understanding of what you're after.
Also consider the sources of the data you're displaying. From a functional spec aspect, simply saying something like 'show this figure here' is easy. From a programming point of view, coming up with the figure in the first place is often the hard bit.
The best you can do is to put the end-user's hat on and describe what you'd like the system to look like / work.
Imagine all pages and create a new frame for each one. Make as many annotations as you can so all bidders know exactly what you are expecting.
I'd also add at the end if it's likely the site's requirements to change during development, so everybody's warned in advance.
Details Details Details.
You might think you have a clear picture, you don't. You need to write every single step down no matter how trivial. You will see there are things you haven't thought of.
Try to write down as much information as you can think of. Go through all the scenarios a user would when using your site. Use steps such as
1) User clicks on Buy Button
2) Screen shows up with 4 items, Link to details, price, quantity and a 32x32 thumbnail.
2a) If User clicks on thumbnail full resolution image i s displayed
etc etc.
Don't try to gloss over the "simple" stuff and you will get the most accurate bid possible!
Basically draw out what you want (ie textboxes, drop down lists, controls, etc) in very simple manner. Then add little numbers around each area that has some functionality. In the margins or on another sheet, describe each point you numbered on the controls with simple instructions on how that functionality should work.
Think of it as a skeleton to describe the application you want.
Not a complete list, but here a couple of thoughts:
Do not forget the back button.
Back button behaviour is an issue on every site I've ever worked on. Specify exactly what you want to happen on every page if the user gets to that page by hitting the back button. Often it's easy, but sometimes it is not at all trivial.
Security:
Do people need to log on, how, how do you create accounts, reset passwords etc. What pages need you to be logged on, what happens if you hit those pages without being logged on.
You could read Joel Spolsky's Painless Functional Specifications for ideas, but I've just tried to summarise what that means for web software too.
I usually do this in 3 stages:
a list of contents, under the headings they'll appear on the site. Get this firmly agreed by all parties before doing any wireframes;
a greyscale functional wireframe in plain HTML/CSS, using examples of real-world content and dummy static pages for dymanic content, with everything where it should be. This is the first thing programmers want to see;
a purely visual graphic mockup of each type of page - this is the next thing programmers like to see, as in 'show me how you want it to look and I'll make it happen'.